NEXUS.IO BLOCKCHAIN 101 FAQs & GLOSSARY DEVELOPER DOCUMENTATION
Home

TECHNOLOGY

USER GUIDES

DEVELOPER GUIDES

FAQs & GLOSSARY

Contracts

Nexus has developed a seven-layered software stack operating as a 64-bit register-based process virtual machine, whereas many of today’s contract platforms still retain the original UTXO architecture, albeit in an account-based form. The more common stack-based script virtual machines (EVM, JVM), handle the translation of an application's source code language to the VMs bytecode, which then executes the instructions. Whereas with Nexus, each layer of the software stack carries out a specialized process, increasing the efficiency of contract processing.

The Nexus virtual machine innately performs many useful actions through a set of operation codes, instructions that define contract logic. Operations mimic actions between people in the real world, by acting on data stored as registers. For instance, Nexus registers store many different types of data including accounts, tokens, names, and digital assets. Nexus currently has 16 primitive operations, which are actions that take place on the register such as: WRITE, DEBIT, TRANSFER, APPEND, etc. These actions cause the register to change its state, including the transfer from one signature chain (a blockchain account) to another. All the actions are recorded in Signature chains as a sequence of transactions.

Unlike other virtual machines, Nexus is built to verify the authenticity, as well as verify the computation of data, making it a very suitable contract engine to build applications for the purpose of verifying data integrity and history, e.g. for digital identity.

To make development more accessible, Nexus has developed domain specific languages for different aspects of contract functionality, including Conditional Contracts and Query DSL.

Conditional contracts allow one to create stipulations (conditional operations) between debits and transfers, allowing users to set requirements, such as contract time expiration, or the decentralized exchange of an asset or token.

A conditional contract consists of: a register pre-state (the register that is being operated on), a primitive operation (only one primitive operation per contract), and a set of conditions (any amount of conditional operations). There are 54 conditional operations and types, such as EQUALS, LESSTHAN, GREATERTHAN, PLUS, MINUS, etc.

For instance, a contract is locked until a specific condition or set of conditions are met, such as a DEBIT of 500 NXS to claim a particular asset. Another example is Nexus’ default conditional contract that prevents NXS from being sent to an invalid address, as the receiver has to claim the transfer within 7 days (a setting which is automatically enabled in the Nexus wallet).

Conditional operations are used to create contracts between different parties that outline a set of requirements that must be met for a transaction to complete. They use boolean logic, meaning that the contract statement either evaluates to true or false, and they have no limit to their complexity, being capable of handling groups of conditions that together evaluate to either true or false. If the statement is true, one can claim what is held in the contract, this could be NXS, a token or a digital asset.

The conditional contract domain-specific language (DSL) is designed for users who want to develop new API’s (Application Programming Interface) or contract standards. It is suitable for people who are familiar with the command interface and would like to delve a little deeper, as it allows them to write conditional contracts on the lower level API, with the use of English words. The main command interface is where the API RESTful commands reside, below this is the DSL. The DSL maps human words into byte code, meaning that developers no longer need to use byte code to program a contract, you can type the DSL directly into the API! Keywords also map into specific sequences, for instance, one word can map into three operation codes.

We have maintained the standard contracts as embedded constants in the codebase. The ability for developers to code new contracts, provides the opportunity for a dynamic standardization using Nexus to manage this state, similar to dynamic object modeling. This approach also allows people to more easily read or interpret contracts.

Query DSL is another contract language that adds capabilities similar to SQL query, including wildcard search and logical operators, enabling one to search or filter any digital asset or token on Nexus directly through the API. For example, one could search Property Titles in Arizona. This feature sets the foundation for a decentralized search engine.

With Nexus, each transaction (debit or credit) is actually a contract itself. It is free to send and receive NXS, tokens and digital assets. However, to prevent transaction spam attacks, a 0.01 NXS fee is applied to every transaction (simple contract) sent within 10 seconds of the last transaction.

Each single transaction can contain a maximum of 100 contracts. Therefore, the transaction fee is calculated based on the number of contracts held within it, at a rate of 0.01 NXS per contract. Adding an expiry to a transaction is free while contract costs are based on complexity, i.e. the operations involved, guaranteeing execution and eliminating the need to worry about a loss of funds due to contract failure. Please check out our fee schedule for more information.

To execute an Ethereum based contract, one is required to set a GAS price and limit. This results in higher fees in times of high network demand, which can cause contracts to fail, while the contract user still has to pay the costs. Therefore, unlike Nexus, the fee for Ethereum based contracts are unpredictable and vary with network demand.

Nexus will be protecting the standards and security of the contracts through a standardization system developed by consensus working groups, in order to provide a range of template contracts that have been tried and tested. The contracts that reach the Nexus standard will then be added to the Nexus API, to make them available to users. For instance, in the future there will be an option in the Nexus wallet to select a contract for a particular use such as a conditional exchange, or an immutable or temporary reversible contract.