Here you will find our fee schedule and a list of guides to help you use the Nexus Wallet for purposes such as registering Assets (NFTs), creating Tokens and Namespaces. If you have any further questions please join one of the Nexus Community Channels found in the footer, and post a message asking for help.
Nexus aims to offer fee-free transactions for the majority of transactions that users make. It is free to send NXS/tokens (OP::DEBIT), and in most cases it is free to receive them (OP::CREDIT). Similarly it is free to transfer an asset or other register (OP::TRANSFER) and in most cases it is free to receive ownership (OP::CLAIM).
To maintain security of the network, a transaction fee is applied, regardless of the types of contracts and operations within it, if the user makes more than one transaction in a 10-second period.
The breakdown of fees for all operation types is as follows:
Sending NXS or other tokens
Receiving NXS or other tokens
If the debit being credited has contract conditions, a fee may apply for executing those conditions depending on their complexity. A fee-free threshold for conditions means that simple contract conditions such as adding an expiry to a debit will mean crediting them will be free
Transferring assets (NFTs) and other registers
Claiming ownership of assets or other registers
If the register being claimed is a named register, i.e. there exists a local name for it in the previous owners signature chain, then a corresponding local name is created for it when claiming. This name creation attracts a 1 NXS fee.
If the transfer being claimed has contract conditions, a fee may apply for executing those conditions depending on their complexity. A fee-free threshold for conditions means that simple contract conditions such as adding an expiry to a transfer will mean claiming them will be free
Creating a NXS or token account
If the account is given a name, there is a 1 NXS fee applied for the creation of the name register.
Creating an asset or other register
The fee is calculated based on the size of data stored in the register at 0.001 NXS per byte. However, there is a minimum fee of 1 NXS, and a maximum register size of 1Kb.
Updating an asset or other register
Creating a local name
Creating a global name
Creating a namespace
Creating a token
The fee calculation for creating a token is based on the number of total supply of token divisible units, which in turn is calculated from the token supply and the number of decimals in the token definition. For example, a token with supply 1,000,000 and 2 decimals has a total of 100,000,000 divisible units. The actual fee calculation is a logarithmic scale based on this number, using the formula:
Fee = (log10(divisible units) – 2) * 100
A minimum fee of 1 NXS always applies. This yields the following fees based on number of divisible units
100 = 1 NXS
A transaction fee is applied whenever a transaction is created within 10 seconds of the last transaction within a signature chain. The fee is calculated based on the number of contracts within the transaction at a rate of 0.01 NXS per contract, of which there can be a maximum of 100 (at the time of writing). Therefore the transaction fee will be between 0 and 1 NXS.
The transaction fee is applied in addition to any of the other fees described in this table.
Assets are non-fungible tokens (NFTs), meaning they are non-divisible. In its simplest form, an Asset is nothing more than arbitrary data stored on the Nexus blockchain in a state register. You as the user can decide what data is stored in that Asset, and depending on the way the Asset is created, whether or not the data in the Asset can ever be changed (is mutable / immutable). Think of it like writing on a piece of paper. You can choose to write what you want on that piece of paper. If you write it in ink then it is permanent. If you write some of it in pencil, then you can erase it and change it to something else.
The Nexus architecture uses state registers for storing many different types of data including Accounts, Tokens, Names, and Assets. A state register sounds fancy, but it is really just a space where information can be stored.
With the Nexus API, you can make special kinds of transactions to create these registers or update / append to the data in them. When the data in a register changes, it is said that the register is 'changing state' from what it was previously to what you are now changing it to - hence the name state register.
Every register on the Nexus blockchain has two main properties: An address (referred to as a register address) which is used to determine the location of the data in the register database, and an owner, which is the genesis hash of the Signature Chain that currently owns the register.
Allowing users to store arbitrary data in a blockchain is not a new concept - we've been able to do that since the early days of Bitcoin. What's unique about Nexus' register-based blockchain is that all changes to a register - including changes to the data and to the ownership of it - are captured in the transactions recorded on the blockchain. Not only does this allow us to validate data changes via consensus rules, but it also allows us to view the entire history of changes to the data in a register and its ownership.
It becomes an audit log for data, allowing users to see what that data looked like and who owned it at any point in time. That's a hugely powerful concept and opens the door to many use cases where a history of the data is required, e.g. supply chains, postal tracking, land/real estate deeds, certificates of authenticity, art watermarking, wills, etc. Each Asset is owned by a Signature Chain, which is great for situations where there is one single owner of an Asset.
However, what about those use cases where partial ownership is required, for example where a piece of real estate is owned by two or more investors and they want to prove their ownership via a public blockchain? Nexus solves this by allowing an Asset to be tokenized, which means that the ownership of an Asset is transferred to a token rather than a Signature Chain. Once tokenized, any users that hold the tokens in their Signature Chain become partial owners of the Asset, much like owning shares in a company.
Furthermore, tokenized Assets provide the ability for shared revenue to be automatically distributed in the form of NXS payments to the partial owners of the Asset, based on the percentage of tokens held. This is useful for use cases such as the automatic payment of dividends for Security Token Offerings (STO's), and for the distribution of royalties from revenue earned from an Asset such as a music album.
The Nexus API provides a straightforward and intuitive interface for users to create, update, and transfer Assets. To create a basic Asset you can use the Wallet console or Nexus command line interface (CLI) and issue a simple command:
assets/create/asset name=myfirstasset data=this_is_some_data
The create/asset API method allows the Asset to be defined in several different formats. Shown above is the basic format, which is the default. In the basic format the data is supplied in key=value pairs, all data is treated internally as a string (a series of alphanumeric characters), and all data is immutable (cannot be changed). The create/asset API alternatively allows complex Assets to be defined using JSON format.
The following example shows how an Asset might be used to store the title deeds to a property:
address=1640 Riversdale Drive, CA
The fee charged for creating Assets depends on the amount of data you are storing. The charge is 0.01 NXS ber byte, with a minimum fee of 1 NXS. This means that the cost of an Asset will be between 1 and 10 NXS depending on how much data it contains.
Currently all registers are limited to a maximum of 1Kb, which is about 1000 characters of text.
You can transfer ownership of an Asset to another Signature Chain with a simple API command specifying the name/address of the Asset you own, and the username/genesis of the recipient:
assets/transfer/asset name=myasset username=bob
In order to update data in an Asset, you have to initially create them using a JSON format, as opposed to the basic format shown above. Using the JSON format allows you to specify field type, length, mutability, and an initial value for each data field in the Asset.
In the broader sense, tokens can be thought of as virtual currencies that exist on a blockchain.
They can be used for a variety of uses such as:
The primary difference is simplicity. To create a token on Ethereum, or most other token platforms, users must write a smart contract - code written in a specific programming language - to define the token and how it will be used/distributed. This requires the user to have programming skills and the task can often be quite complicated. Nexus has taken a different approach by simplifying the process, allowing users to create a token in one short console command / API request. The wallet interface goes a step further providing a simple interface to guide users through the process.
The tradeoff for simplicity is flexibility. A token created from a traditional smart contract allows developers to define any rules they wish for the distribution and use of a token, which are encoded in the token definition contract. This flexibility is certainly useful, but is overly complex for people without programming skills.
Nexus decouples the contract rules from the token definition allowing the token creation to be far simpler, though provides further steps if more complex rules are needed. For those use cases that require more complex token utility, Nexus users can add contract rules as conditions to token debit transactions.
If the rules are too complex to be supported by a transaction condition, developers can write these rules into their application layer.
When you first create a token you must specify the supply (the maximum number of whole tokens that will be available) and decimals (the number of decimal places that a token amount can have).
The combination of these two values gives the number of token divisible units that will be available (the equivalent of Bitcoin’s Satoshi’s property). For example a decimals value of 3 means that each token can be divided into 10^3 (1,000) parts. Therefore a token created with a supply of 1,000,000 and decimals of 3 would result in 1,000,000,000 (1,000,000 x 1,000) token divisible units. This is important, as this figure is what is used to calculate the fee applied when creating the token.
Once created, the token has three important properties:
Tokens can easily be created through the Nexus Wallet or the console/CLI. The user defines a new token so that it can be distributed, traded, or used to tokenize an asset.
To create a new Token, go to the User module in the Wallet, and please follow the below instructions:
To achieve the same using the console use the following command:
tokens/create/token name=My Token supply=100 decimals=2
The fee is based on the number of token divisible units you define (the combination of supply and decimals). There is a minimum fee of 1 NXS and the calculation is linear thereafter, so that each additional significant digit costs an additional 100 NXS. E.g.
100 units = 1 NXS
1000 units = 100 NXS
1000000 units = 400 NXS
10000000000 units = 800 NXS
Initially all of the token supply is held in the balance of the token. Distributing your token to other users is then very similar to how you send NXS. The first step is that the receiving users must create a new account for your token type and then provide you with the account name/address. Then you can use the wallet interface to send them just like you would send NXS, choosing the token from the Send From list. Alternatively, you can use the console with the following command:
tokens/debit/token name=My Token name_to=paul:tokenaccount amount=1000
At the time of writing, no the maximum supply cannot be changed once the token has been created. However, this ability is planned for a future release. How do I use a token to represent partial ownership of a digital or real-world asset?
One of the most significant use cases for tokens is the ability to tokenize an asset. Tokenized Assets provide the ability for shared revenue to be automatically distributed in the form of NXS payments to the partial owners of the Asset, based on the percentage of tokens held. This is useful for use cases such as the automatic payment of dividends for Security Token Offerings (STO’s), and for the distribution of royalties from revenue earned from an Asset such as a music album.
Simply put, tokenizing an asset means to digitally represent the value and ownership credentials of a real world asset in a secure and easily transferable manner on the internet using blockchain technology. We refer to this digital representation of data as a token.
Nexus utilizes Signature Chains (SigChains) technology to simplify the creation of tokenized assets and validate ownership on the Nexus blockchain. Once created, a token (and all the value & rights associated with it) can be easily transferred from one SigChain to another (or in other words, from person to person). In other words, if we transfer ownership of an example real estate property to a token called, for instance, "Ownership_1020_Greengate_Dr_Columbia_SC_29229", and the amount of that token is 100, the token can serve as a percentage of ownership in the property. So, someone buying in 10% ownership in the property would receive, in exchange for their money, 10 of the ownership tokens. Alternatively, if someone purchased 50% ownership in a self portrait asset, they would receive half of the available tokens associated with the asset, which might be called "Ownership in Self Portrait".
For the purposes of this article, there are two primary reasons for tokenizing an asset. First, it can store asset ownership permanently by the person who owns the tokens. For the self portrait asset, this percentage ownership can be made accessible via DApp created for the purpose of reporting high-value asset ownership. Second, it can automatically distribute revenue associated with the asset to the owners according to the allocated percentages. In the case of our fictitious real estate property, when the occupant pays the rent, 10% of the rent paid will be automatically transferred to the signature chain which owns 10% of the "Ownership..." token for this asset. This can be done with NXS (the cryptocurrency itself) or with a fungible token that the owners of the property agree to accept as rental proceeds, using the same mechanism used to send NXS or a token to any other address on the Nexus network.
Briefly, an asset is a user-definable entity that is recorded on a SigChain. Examples of assets used for this article include a) a real estate property and b) a high-value work of art. On the blockchain, a real estate property asset might be represented with fields containing a tax identifier, a URL to a deed, and a hash used to verify the integrity of the deed file.
For the high-value work of art, one might represent the asset with fields containing the artist, creation date, a URL to a certificate of authenticity, and a hash to verify the integrity of that certificate file.
assets/create/asset name=Self Portrait artist=Neal Helman
Rest assured that the above examples are purely fictional. The assets and documents referenced do not exist. The API calls, however, exemplify how you might create an asset from the console in the Nexus wallet. This guide will also look at how one would use the wallet to do the same things demonstrated here with the console and API calls. It is anticipated that someone will create a DApp that will allow such assets to be created in a more industry-appropriate manner.
The following screenshot shows the location in the wallet to create an asset. On the User screen, in the Assets tab, click the Create new asset button to begin creating a new asset.
The next screenshot shows the fields filled in for the real estate asset. Note that none of the fields are numeric, so they are all string types, and none of them can be changed in the future meaning their mutable buttons are turned off. Upon scrolling to the bottom of this screen, one will see the button for submitting the fields and creating the asset. The user PIN for the SigChain is required in order to confirm the creation of the asset.
As mentioned previously, two tokens will have to be created for the purpose of tokenizing our two fictitious assets. The API calls below show how one might create these two tokens, with the assumption being that we only need 100 tokens to represent percentage ownership. For this example, fractional percentage ownership of up to four decimal places can be used (e.g., 5.1200%). Of course, one would provide the proper PIN for the SigChain on which the tokens are being created.
name=Ownership in Self Portrait
The following screenshots shows the corresponding process using the wallet of creating the token representing ownership in the real estate asset. First, on the User screen, go to the Tokens tab. There you will see the Create new token button.
This screenshot demonstrates the filled fields for the real estate asset’s ownership token. The supply is set at 100 to easily represent percentage amounts, and by allowing 4 decimal places, someone might have 45.5123% ownership in the asset. Note that with this supply parameter, the fee for creating this token is currently 400 NXS. Click the Create token button to submit the form fields and create the token.
The formula for calculating the fee for creating a token is (log10(TotalSupply) - 2) * 100 NXS, with a minimum of 1 NXS. TotalSupply is the number of divisible token units, so, in our case 100 tokens divisible into 4 decimal places is 1,000,000 divisible units. Thus, 400 NXS to create this token.
After creating the token, the wallet prompts to create an account. This isn’t a requirement unless the SigChain (in this case, bobby.walsh) will also be represented in the ownership of the asset.
Now that the assets and tokens have been created, the asset can be tokenized. The following API calls illustrate how this might be done from the Nexus wallet console.
name=Self Portrait token_name=Ownership in Self Portrait
Note that, as with most of the API calls, the asset and token addresses can be used as an alternative to the names that are used in the example above. Here is what it looks like when these API calls are issued from the wallet’s console.
Once the assets have been tokenized, the tokens can be distributed to the owners in their allotted percentages. Note that to participate in the ownership of the assets, the SigChain on which the assets and tokens were created will also need accounts for the tokens used to tokenize the assets, and will also need tokens sent to those accounts.
The next screenshots demonstrate the process of creating an account for the token just used to tokenize the real estate asset. The account is being created on the SigChain of claudia.hush, who we will then give 45% ownership of the real estate asset to.
First, Claudia needs to look up the token for which she will create the account. The lookup function is on the User screen in the Tokens tab. At the top right of the tab is a Lookup a token button. Clicking that button displays the following input where she can enter the fully-qualified name (e.g., including the SigChain) of the token representing ownership in the real estate asset. The Lookup this token button retrieves the token information from the blockchain.
Here we see that Claudia has found the token. She can now create the token account on her SigChain by clicking the Create new account with this token button. On the resulting prompt, she confirms to create the account.
Now that the SigChains of the owners have accounts for the tokens with which the real estate asset was tokenized, the owner of the token (e.g., bobby.walsh) can transfer a percentage of tokens to the accounts in order to represent partial ownership. This includes a token account on his own SigChain as well as a token account on the SigChain of claudia.hush. The following screenshot demonstrates Bobby transferring 45 tokens (45% ownership in the real estate asset) to Claudia’s token account.
After transferring the remaining tokens to his own token account, the following screenshot reflects that Bobby now owns 55% ownership in the real estate asset.
Once Claudia’s 45% ownership in the tokenized asset is represented by her SigChain’s possession of 45 of the tokens used to tokenize the asset, she qualifies for 45% of the revenue paid to the asset. For our example, a third entity, harry.twilight is paying rent on the real estate asset, in this case 100 NXS. In addition to NXS, he could have paid with any fungible token residing on the Nexus blockchain. As seen below, Claudia receives 45 NXS from Harry’s payment of 100 NXS (topmost CREDIT transaction). The second topmost transaction shows where Claudia received the 45 tokens representing her ownership stake in the real estate asset.
Nexus has simplified the blockchain tokenization process so that even ordinary users can monetize their own creations with appropriate royalty allocations. This has wide reaching implications to a variety of industries. Many of the applicable use cases and respective industries are depicted in the diagram on the What is Nexus webpage.
This guide provides details on how to install the Nexus Invoice System module, create a new invoice, and pay an invoice. Screenshots from the current Nexus wallet along with descriptions provide users with the knowledge required to use this fairly simple module for accounting tasks on the Nexus network. To read more about the applications of the system, please read Invoicing.
The Module section of the Nexus wallet is accessible via the top Settings menu or gears icon on the bottom. Choose the Modules section within the Settings screen. The following screenshot shows the Modules section without any modules installed.
As the instructions on the screen indicate, installing a module is as simple as dragging a module's archive file (e.g., tar.gz archive file) into the field on the screen.
Upon dragging the invoicing module’s archive file onto the screen depicted above, the following prompt is displayed. If everything is as expected (e.g., the module hash matches that listed on the github repository), click the Install Module button to begin installation.
The following prompt is presented to indicate that the module has been successfully installed. Upon dismissing this prompt, the wallet will be restarted.
Now, as a result of installing the invoicing module, it is included in the list of installed modules, and the toggle button indicates that the module is active.
Note also that a new icon has been added to the bottom of the wallet for the Nexus Invoice System.
Running the Nexus Invoice System is as simple as clicking on the icon at the bottom of the wallet screen which was added when the module was installed. The first time the module is run, the Nexus Invoice System is displayed with an empty list of invoices. On subsequent review after creating invoices, this is where they will be listed.
Before getting into the creation of invoices, it is worth noting that the More options dropdown displayed above reveals additional fields with which invoices can be searched, as shown in the screenshot below. These fields include Description, the Payable account, the Recipient identifier (e.g., the username for a SigChain), and a toggle to cause only past due invoices to be displayed.
To create a new invoice, click the +New Invoice button shown in the above screenshot. The following screen is displayed where details comprising this invoice are entered. These details include Description, Reference (typically used to tie an invoice and payment to an accounting ledger item), Number (used to help identify particular invoices), and Due Date.
In the From group of fields, the Account Payable information for this invoice is specified, which is used to indicate which account within the sender’s SigChain will receive the funds once paid. In addition, the Sender Details for this invoice can be specified, for instance, to include the human-readable name of the person being paid in this invoice.
The following screenshot shows the dropdown in the From section which lists the accounts to where the funds for this invoice could be paid. Choose one from the list.
The next screenshot shows in the To section, the Recipient field is filled out. This field takes the username or hash of the SigChain that will be paying this invoice. Below that, in the To section, Recipient Details could be included such as the human-readable name associated with the paying SigChain (if the hash is being used to identify the SigChain).
Further down on the invoice screen, the Items section holds the specific elements being invoiced. In the example shown below, the recipient is being invoiced for laptop upgrade items: memory, an SSD, and labor. For each item, the unit cost in NXS is provided, as is the number of units being invoiced. The module multiplies these to get the Total for each item. It also totals all items to show the Total for this invoice at the bottom right. The total is listed in NXS and the currency configured to be shown in the wallet (in this case USD).
Note that the invoice screen has two buttons at the bottom of it: Submit and Save As Draft. Next to the Submit button the fee in NXS for submitting the form is displayed.
The following screenshot shows the invoice saved as a draft. Note that at this point, the Reference does not display. However, draft invoices can be displayed by selecting DRAFT from the Status dropdown at the top of the invoice module.
Upon clicking the Submit button to send an invoice to the recipient, the following prompt is presented to enter the PIN for the SigChain from which the invoice is being sent.
After submitting an invoice, it displays in the list of invoices with a Status of OUTSTANDING. Note that this is how the invoice will be displayed to both the sender and receiver.
If the sender wants to cancel the invoice, they should open the invoice and click the Cancel button. A prompt to enter the sender’s SigChain PIN will be presented, and after entering the PIN, the invoice will be marked CANCELLED.
To pay the invoice, the receiver clicks on the invoice in the list of invoices (as displayed above). The following prompt will be displayed.
Clicking the Pay button presents a prompt allowing the payer to choose an account from their SigChain from which the invoice will be paid. The dropdown on this prompt lists all available accounts from which the payer can choose.
After selecting the payment account, the payer clicks the Pay with this Account button to indicate their designation. A confirmation prompt, shown below, is presented to validate the payer’s intention to fulfill this invoice.
As a final confirmation and authentication, when the payer clicks the Yes button (above) to indicate their confirmed intention to fulfill the invoice, they are presented with a prompt to enter their SigChain’s PIN.
Finally, the invoice is marked PAID. The screenshot below depicts what displays in both the sender’s and receiver’s list of invoices in the invoice module.
The following screenshot shows from the receiver’s perspective the transaction resulting from paying the invoice. The screenshot was taken before any blockchain confirmations of the transaction had been applied.
The ensuing screenshot shows both the invoice creation transaction (the lower one with the FEE deducted) and the transaction in which the sender has been paid.
This concludes the basic instructions for invoice usage and functions. More features are under development and this guide will be updated as these are released. If you have any questions, comments or suggestions please feel free to reach out on our social media channels or github page that are linked at the bottom of this webpage.
This guide describes namespaces and namespaced names on the Nexus blockchain. Examples of creating namespaces and associated names are given using both the interface provided by the Nexus Wallet and API.
When creating an account, token, or asset, a name can be assigned to it. For instance, upon creating an asset called “Self Portrait” in the “bobby.walsh” Signature Chain (SigChain), it can be referenced by the string “bobby.walsh:Self Portrait”. However, you can also assign more globally-accessible names to these objects using namespaces and namespaced names. For our example, consider that we create a namespace “bobbywalshartgallery”, and within that gallery, we create a name “Self Portrait” that points to the same address on the blockchain belonging to the asset “bobby.walsh:Self Portrait”. This way, instead of giving out the SigChain username “bobby.walsh”, the business “bobbywalshartgallery” can be the public point of access, allowing people to reference the Self Portrait asset as “bobbywalshartgallery::Self Portrait”.
Note that when names are referenced with a SigChain, a single colon (“:”) is used, while when names are referenced as part of a namespace, two colons (“::”) are used. So, the namespace is a globally-accessible container for names, and the names within it are pointers to objects on any SigChain. Please also note that creating a namespace in Nexus incurs a fee (currently 1,000 NXS), while creating names within that namespace only costs 1 NXS.
To begin with, consider our example above, an asset “bobby.walsh:Self Portrait”. In the wallet, it looks like this:
1. If the ownership of this asset is going to be transferred by Bobby Walsh's Art Gallery business, Bobby doesn't necessarily want to give out his SigChain username. The first thing he must do is create a namespace for his business. The image below shows the User screen where namespaces can be created. Note the tab name on the left (Namespaces) and the button Create new namespace.
2. Upon clicking the Create new namespace button, the following dialog is displayed. This shows the name field filled in for the bobbywalshartgallery. Note that the name of a namespace can only contain lowercase letters, numbers, and periods.
3. Next, the wallet prompts for the SigChain PIN to confirm creation of the namespace.
4. Upon creation of the namespace, a success prompt is displayed. Click Dismiss to close the prompt.
5. Upon dismissing the success prompt, the list of namespaces is displayed. The image below shows the namespace that was just created.
Now that the namespace has been created, the name pointing to the asset in our example (“Self Portrait”) can be created.
1. First, click the pane displaying the “Self Portrait” asset in the Assets tab of the Users screen. It displays the following, from which the asset's address can be copied to the clipboard.
2. Next, click the Names tab of the Users screen. The following will be displayed, showing all names associated with this SigChain.
3. Click the Create new name button to begin the process of creating a namespaced name. A dialog is displayed to allow creation of a new name. When dialog appears, click the NAMESPACED button at the top of the dialog to specify creation of a name in a namespace.
4. This image shows the fields filled in for our namespaced name example, “bobbywalshartgallery::Self Portrait”. First, select a namespace owned by the currently logged-in SigChain. Then fill in the field for the name. Note that the namespace is provided in the NAME field, and to enter a name in the field, the cursor must be placed after the namespace placeholder. Finally, provide the asset address retrieved above to point the new name to the specific asset in question. A 1 NXS fee will be charged for creation of the namespaced name.
5. Upon clicking the CREATE NAME button, a confirmation prompt requiring entry of the SigChain's PIN appears. Entry of the PIN results in the namespaced name being created, and the following success prompt being displayed.
Upon dismissing the success prompt, the Names tab of the Users screen is displayed again, and the new namespaced name is visible in the list of names. Note that to the right of the namespaced name is an indicator, NAMESPACED, to highlight this as a namespaced name, distinct from a local name.
Clicking on the new namespaced name results in an information screen being displayed showing the details on the namespaced name.
From the Name Details screen, the namespaced name can be edited to point to a different account, token, or asset by clicking the pencil icon at the top-right of the screen. The following screen displays, with the current destination address being highlighted. This address can be changed, and then click the UPDATE NAME button. Note that a fee of 1 NXS is charged for changing the destination address of a namespaced name.
Also, from the Name Details screen shown previously, the Transfer ownership button can be pressed to begin the process of transferring the namespaced name to a different SigChain. The destination SigChain's username or address can be used to transfer ownership of the namespaced name to it.
Now, as proof that the namespaced name points to the desired asset, from the wallet console, the following command can be entered, and information pertaining to the asset is returned.
Consider that the Nexus API can be used to programmatically create namespaces and namespaced names. The following screens will demonstrate this by using the Nexus wallet console. This shows how the API commands could be issued from a DApp to achieve the same ends.
1. First, log into the SigChain that will contain the namespace and namespaced name. Then, the following command can be issued to create the namespace. Of course, the pin parameter must be the PIN of the SigChain.
2. The following API command is then issued to create the namespaced name. The register_address parameter contains the Address hash that was retrieved from the target asset's property screen. (See step 1 in the preceding section showing how to use the wallet to create namespace and namespaced names.)
3. Now, the name can be programmatically retrieved using the following command.
4. More importantly, the underlying asset itself can be programmatically retrieved by issuing the following API command.
For more information on available API methods, refer to the GitHub API documentation. Please use our Forum, Slack, Telegram or Discord support channels at the bottom of the page for further inquiries and support.