Developer-Friendly APIs — Nexus Blockchain

Developer-Friendly APIs — Nexus Blockchain

With the highly anticipated release of the Nexus Tritium Mainnet scheduled for the end of January 2019, application developers will be able to interact with the functionalities of the Nexus blockchain through an easy to use, feature-rich API set. APIs will create user-friendliness for developers who will be able to build in a wide range of languages, and interoperability for existing private systems to interact with the Nexus blockchain. Nexus has designed its software stack based on the Open System Interconnection (OSI) network reference model, with the fifth layer as the API layer.

Nexus software stack

What is an API?

An API is an Application Programming Interface. While a user interacts with a system through a user interface, an API allows developers to interact through a programmatic interface. The way this works is that the API provides a list or set of simple commands that execute a series of operations, which would otherwise require specialist programming knowledge. This allows a developer to request or submit data to a system providing functionality to a higher-level application. For example, Facebook’s Graph API allows access to “Login with Facebook” and other features of their system.

Hybrid Blockchain

The distributed validation method provided by a public blockchain or Distributed Ledger Technology (DLT) (on-chain) is very secure in comparison to that of a private blockchain (side-chain) or centralized database (off-chain), because it is validated by many nodes forming a global consensus. However, private blockchains which are serviced by their own nodes provide other benefits that are much easier to develop and scale. One such benefit is to record proofs of private, sensitive, or proprietary data that are generally stored in a private database. This provides the private database the ability to edit or delete this data, in order to comply with regulations such as General Data Protection Regulation (GDPR), while maintaining the positive qualities of immutable proofs from the private blockchain. An optimum balance between a Public Ledger, Private Ledgers, and Private Databases, will provide the performance and efficiency necessary for global adoption.

Nexus hybrid blockchain

Nexus is developing the systems to enable private networks to utilize the public ledger, creating what is essentially a hybrid system, through an array of both private and public ‘template’ use case APIs. Public APIs will be provided by Nexus as open source technology, while Private APIs will be developed with businesses as their proprietary technology.

Public API

Through the Nexus API, developers building higher-level applications for consumers and producers of digital data will be able to access the various functionalities of the Nexus blockchain: Advanced Contracts, Cryptographic Identity, and the DLT. The Tritium wallet will provide the interface where all Public APIs will be accessible through HTTP-JSON, providing a set of single commands which will execute a series of events down through the Nexus software stack rather than using a specific Turing-complete language, requiring specialist programming knowledge. This will allow developers to build in a wide range of languages, such as C++, C#, Java, Python, and Javascript.

Nexus welcomes any interested parties to participate in our working groups to help shape the standardization process for the Nexus Software Stack, as we continue to develop the standardization body for DLT, similar to how the Internet Engineering Task Force (IETF) shapes the internet.

Private API

In addition to accessing the Public APIs, developers will be able to build their own Private APIs, providing the privacy of a permissioned system required to keep proprietary information and logic concealed, while harnessing the security of a public blockchain. This is possible through the use of state recording checkpoints between the private and public networks to ensure that agreements in the private network are also recorded in the public network, shown by the diagram below.

Given that only the aggregated state of the private ledger is recorded, sensitive or private data is not stored on the public ledger. Therefore, private APIs can secure proprietary contract logic, such as private supply chains, notaries, consumer verification services, etc., providing private services that the public layers are unable to. Since a private API functions as its own private network that synchronizes to the public network, one can expect the level of reliability and security of DLT. A private network can be operated under a software services license, or by the commissioner of a said API service. The final result, is a robust service that provides interoperability with existing private systems.

Nexus Private API Service for Enterprise range from hosting solutions to full private API buildout. Private APIs can be custom-built either by Nexus on behalf of a private client, or by any third party with or without consultation. Private testnets can also be provided during development to avoid loading the public and final private ledger with redundant data.

Blockchain Accessibility

It is often claimed that the ratio of demand to supply for blockchain developers is 20:1, which has led to the high costs associated with blockchain development and low business adoption. Since most programmers are already comfortable interacting with an API, building on the Nexus API can be as simple as developing a web-app. Through improvements in accessibility, Nexus is set to significantly reduce the barriers to entry for blockchain technology.

Enterprise API enquiries contact: [email protected]

Working Groups contact: [email protected]

The TAO — Tritium Development Update #2

The TAO — Tritium Development Update #2

Welcome to the next update of the TAO update series, to continue the journey through the development of the TAO Framework. This particular article is centered around Tritium, our version 3.0 software client.

Are we ready?

Alright, here we go. The following includes a list of all the most recent code changes since the last “git pull origin master”.

Dockerfile | 17 +-
build/SK.d | 13 ++
config/.aliases | 1 +
config/run-nexus | 8 +-
lisp/RL | 9 +-
makefile.cli | 43 + — —
src/LLC/hash/SK.cpp | 38 — —
src/LLC/hash/SK.h | 13 +-
src/LLC/hash/SK/KeccakDuplex.c | 10 +-
src/LLC/hash/SK/KeccakSponge.c | 6 +-
src/LLC/hash/SK/skein.cpp | 2 +-
src/LLC/hash/SK/skein_block.cpp | 2 +-
src/LLC/hash/Skein3Fish/include/skeinApi.h | 2 +-
src/LLC/hash/Skein3Fish/include/threefishApi.h | 2 +-
src/LLC/hash/Skein3Fish/skein.c | 2 +-
src/LLC/hash/Skein3Fish/skeinApi.c | 2 +-
src/LLC/hash/Skein3Fish/skeinBlockNo3F.c | 2 +-
src/LLC/hash/Skein3Fish/skein_block.c | 2 +-
src/LLC/hash/Skein3Fish/threefish1024Block.c | 4 +-
src/LLC/hash/Skein3Fish/threefish256Block.c | 4 +-
src/LLC/hash/Skein3Fish/threefish512Block.c | 4 +-
src/LLC/hash/Skein3Fish/threefishApi.c | 2 +-
src/LLC/include/key.h | 58 ++++ —
src/LLC/include/random.h | 72 ++++ — —
src/LLC/key.cpp | 541 +++++++++++++++++++ — — — — — — —
src/LLC/random.cpp | 149 +++++++ — — — —
src/LLC/types/bignum.h | 18 +-
src/LLC/types/uint1024.h | 16 +-
src/LLD/global.cpp | 20 ++
src/LLD/include/global.h | 25 +++
src/LLD/{templates => include}/journal.h | 0
src/LLD/include/ledger.h | 66 +++++++
src/LLD/include/local.h | 67 +++++++
src/LLD/include/register.h | 51 ++++++
src/LLD/{templates => include}/version.h | 28 + —
src/LLD/templates/filemap.h | 286 ++++++++++++++++ — — — —
src/LLD/templates/hashmap.h | 415 +++++++++++++++++ — —
src/LLD/templates/key.h | 50 +++ —
src/LLD/templates/pool.h | 617 ++++++++++++++++++++ — —
src/LLD/templates/sector.h | 710 +++++++++++++++++++ — —
src/LLD/templates/transaction.h | 65 ++++ — -
src/LLP/hosts.cpp | 30 ++-
src/LLP/include/inv.h | 2 +-
src/LLP/include/legacy.h | 188 + — — — — — — — — —
src/LLP/include/network.h | 9 +-
src/LLP/include/permissions.h | 28 + —
src/LLP/include/tritium.h | 310 +++++++++++++++++++++++
src/LLP/include/version.h | 40 ++ —
src/LLP/legacy.cpp | 71 +++ — — –
src/LLP/packets/legacy.h | 195 ++++++++++++++++++++
src/LLP/packets/packet.h | 82 +++++++++
src/LLP/packets/tritium.h | 173 ++++++++++++++++++
src/LLP/socket.cpp | 74 ++ — — —
src/LLP/templates/connection.h | 247 +++++++++++++++++++
src/LLP/templates/data.h | 47 +++ —
src/LLP/templates/ddos.h | 177 ++++++++++++++++++
src/LLP/templates/events.h | 41 +++++
src/LLP/templates/server.h | 29 ++-
src/LLP/templates/socket.h | 26 ++-
src/LLP/templates/types.h | 440 + — — — — — — — — — — — — — — — —
src/LLP/tritium.cpp | 321 ++++++++++++++++++++++++
src/TAO/API/{ => include}/rpcserver.h | 0
src/TAO/API/rpcdump.cpp | 4 +-
src/TAO/API/rpcserver.cpp | 20 +-
src/TAO/Ledger/block.cpp | 213 ++++++++++++++++++++++
src/TAO/Ledger/checkpoints.cpp | 168 ++++++++ — — — — –
src/TAO/Ledger/global.cpp | 2 +-
src/TAO/Ledger/include/create.h | 38 ++++
src/TAO/Ledger/include/global.h | 4 +-
src/TAO/Ledger/include/supply.h | 10 +-
src/TAO/Ledger/supply.cpp | 50 ++ — -
src/TAO/Ledger/transaction.cpp | 107 +++++++++++
src/TAO/Ledger/trust.cpp | 2 –
src/TAO/Ledger/types/block.cpp | 315 — — — — — — — — — — — — — — —
src/TAO/Ledger/types/{include => }/block.h | 89 +++ — — —
src/TAO/Ledger/types/{include => }/data.h | 0
src/TAO/Ledger/types/include/transaction.h | 66 — — — -
src/TAO/Ledger/types/{include => }/locator.h | 2 +-
src/TAO/Ledger/{include => types}/sigchain.h | 0
src/TAO/Ledger/types/{include => }/state.h | 0
src/TAO/Ledger/types/transaction.h | 226 ++++++++++++++++
src/TAO/Legacy/{types => }/address.cpp | 8 +-
src/TAO/Legacy/{types => }/enum.cpp | 2 +-
src/TAO/Legacy/include/keystore.h | 14 +-
src/TAO/Legacy/include/wallet.h | 30 + —
src/TAO/Legacy/keystore.cpp | 14 +-
src/TAO/Legacy/{types/transaction.cpp => legacytx.cpp} | 31 ++ —
src/TAO/Legacy/{types => }/outpoint.cpp | 0
src/TAO/Legacy/{types => }/script.cpp | 24 + —
src/TAO/Legacy/{types => }/secret.cpp | 6 +-
src/TAO/Legacy/{types => }/txin.cpp | 0
src/TAO/Legacy/{types => }/txout.cpp | 0
src/TAO/Legacy/types/{include => }/address.h | 2 +-
src/TAO/Legacy/types/{include => }/enum.h | 0
src/TAO/Legacy/types/{include => }/inpoint.h | 0
src/TAO/Legacy/types/{include => }/merkle.h | 2 +-
src/TAO/Legacy/types/{include => }/outpoint.h | 0
src/TAO/Legacy/types/{include => }/script.h | 2 +-
src/TAO/Legacy/types/{include => }/secret.h | 4 +-
src/TAO/Legacy/types/{include => }/transaction.h | 2 +-
src/TAO/Legacy/types/{include => }/txin.h | 0
src/TAO/Legacy/types/{include => }/txout.h | 0
src/TAO/Legacy/wallet.cpp | 66 +++ — —
src/TAO/Legacy/walletdb.cpp | 21 + —
src/TAO/Operation/include/enum.h | 54 ++++++
src/TAO/Operation/include/execute.h | 477 +++++++++++++++
src/TAO/Operation/include/operations.h | 83 — — — — –
src/TAO/Operation/include/stream.h | 150 +++++++++++++++
src/TAO/Operation/include/validate.h | 54 ++++++
src/TAO/Register/account.cpp | 27 +++
src/TAO/Register/include/enum.h | 33 ++++
src/TAO/Register/include/object.h | 46 +++ —
src/TAO/Register/include/state.h | 143 +++++++++++ — —
src/TAO/Register/objects/account.h | 100 ++++++++++
src/TAO/Register/objects/escrow.h | 55 ++++++
src/TAO/Register/objects/order.h | 49 +++++
src/TAO/Register/objects/token.h | 116 ++++++++++++
src/Util/args.cpp | 10 +-
src/Util/base58.cpp | 6 +-
src/Util/config.cpp | 8 +-
src/Util/debug.cpp | 53 +++ — -
src/Util/include/allocators.h | 12 +-
src/Util/include/convert.h | 2 +-
src/Util/include/debug.h | 13 +-
src/Util/include/hex.h | 6 +-
src/Util/include/mutex.h | 46 +++ —
src/Util/include/parse.h | 42 ++ — -
src/Util/include/runtime.h | 112 ++++ — — — —
src/Util/include/signals.h | 63 +++++++
src/Util/include/strlcpy.h | 6 +-
src/Util/macro/header.h | 6 +-
src/Util/templates/serialize.h | 388 +++++++++++++++++++ —
src/main.cpp | 189 ++++++++++ — — — — –
133 files changed, 5885 insertions(+), 3980 deletions(-)

Wow, that’s a lot of changes. It’s interesting to look back on it and see how much has been accomplished. As shown here, there was a total of 5,885 new lines of code, with 3,980 lines replaced. This generally means that there was some older code replaced with new, better code, along with almost 2,000 lines of new and fresh code.


Now we get to explore what it is that was changed on the more granular detail level, to present to you what will be included in the Tritium update.


Since the last update, there have been some improvements to the Network, or the LLP in our instance. So what is it that makes the network important?

The network is responsible for all end-to-end communication.

If the network was unable to propagate messages, the core peer to peer network would be unable to function. The crypto (LLC) in our case is an overlay for certain network messages to deal with cryptographic objects such as our transactions or blocks. Let us look at the newest results of the LLP in action (you would have also seen this in my Tritium presentation at the 2018 Nexus Conference, linked here:

Here it’s good to see requests top out at 197,744 per second as the LLL is the foundation for the TAO, hence the repository name LLL-TAO (shhh, you’ll see the code soon enough if you can find it).

The next aspect of the Network that was formally demonstrated by Dino Farinacci is the LISP architecture, and how it fundamentally works together with the Ledger to provide a safer data layer on the internet. As we know right now, there are a lot of the same problems with identity: it used to be seen that the internet was a place full of fake accounts, trolls, and misinformation. Lately though, we have discovered that the internet can be full of amazing things and incredible possibilities for promoting the ideas of freedom and prosperity.

Make sure to check out Dino’s zoom meeting (Oct 25, at 4:30 PDT) going over this in more depth:

Now, one of the reasons the network has been plagued with the negative aspects is that there is no trust layer in the actual system. We have no way to identify someone other than their IP address which is easy to forge or fake by any means. This can create problems, because one cannot reliably know who they are talking to (this doesn’t mean they need to know personal information, but rather consistency across identities). Now, with tying LISP and Nexus together over the ledger, we create the ability to establish a cryptographic identity of the user. This happens over the network with the static EID in LISP, and over the ledger with a signature chain for a user. This becomes very important for reducing fraud and identity theft, which is one of the focal points for Nexus.


The ledger consists of the series of events that establish the ownership of any register in the stack. This makes the ledger operate very quickly, since it doesn’t have an incredible overhead in processing requirements beside general cryptographic functions. The biggest bottleneck of the Ledger falls under the LLC (Lower Level Cryptography), as this is where the cryptographic verification happens. The newest results of a Ledger scaling test (transactions only, no blocks in this test) shows over 4.3k tx/s capable of being processed by a single node.

This generates a good picture of what a full LLL stack running real transaction data over it would look like. This shows that the LLD is easily keeping up with the demand of writing over ~1,500 Kb/s (Bitcoin has a maximum of ~1.7 Kb/s). The reason for the slowness in Bitcoin is because of the block size limit of 1Mb every 10 minutes. In this case, we wanted to demonstrate the efficiency of the LLL stack in its capability to handle large loads of data. This particular example shows the maximum processing capabilities of one node, which essentially would be the limits of one L1 state processing channel. The signature aggregation being passed from L1 to L2 through L1 verification nodes in a 3DC would enable greater levels of the scalability without sacrificing the security of a global set of consensus validators.

Signature Chains?

Operating well, with a simple data structure that allows easy indexing and locating of the signature chain transaction history and identification of register ownership. Since the signature chain GenesisID is of a 256-bit number space, it is easy to transfer the permissions of a register to be owned by a signature chain, or simply another register. This sets the foundation now of the Nexus Digital Identity System.


Let’s recap what a register is for better context here:

A register is a data object that changes state through global consensus, or a logical layer application.

Why are registers important?

Computers are state machines by nature. They contain a value that correlates to something on the outside world and change this value based on a sequence of logic. I know this sounds complicated, but in reality, it is quite simple.

If I have 5 apples, I record this number in a register I own to prove I have these 5 apples. When other people can ask me how many apples I have, I can give them my register address, and they can see, ahh, viz. has 5 apples. Now if I sell an apple, let us say through an order I put on the network saying: I’ll give you this 1 apple if you give me 0.1 NXS, then we are able to have state changes recorded and verified by the network, correlated to financial transactions.

This means that if someone were to make this transfer into my contract order it could execute the state change of my total apples of value 5 to value 4, while I send off the apple to the lovely customer. This is a crude example, I know, but the intention of it is not to show secure program logic — but rather, logic that shows the use of a register on Nexus.

Now that we have gotten this out of the way, let us look into what Object registers have been defined as of this update:

src/TAO/Register/objects/account.h | 100 ++++++++++
src/TAO/Register/objects/escrow.h | 55 ++++++
src/TAO/Register/objects/order.h | 49 +++++
src/TAO/Register/objects/token.h | 116 ++++++++++++

Each of these 4 objects are objects that can have the state changed through the ledger consensus mechanism. This is important for Tokens, Escrow, Orders, and Accounts as I shouldn’t be able to modulate the balance of my account without approval from the network. The downside to having the ledger do all the state changing of the registers through the operation codes is the resource requirement of all nodes to process this state change and ensure that it does not create a conflict with another state. It becomes very important to find the balance between logical and ledger state changes, as the network doesn’t always need to know everything that the logical layer is doing, and the logical layer shouldn’t be doing everything that the ledger is doing. This distinction is important for understanding how Nexus Advanced Contracts will scale to levels of requirement for mass adoption.

Raw State registers on the other hand are defined through specifications on the Logical layer. They operate very quickly because nodes only need to write the data, address, and owner of the register. Only the owner of this register will be capable of writing a new state to it if it is not defined as read-only. This allows the Logical / Interface layers (The Application Space) to state record important data to their system such as hashes to IPFS files, private database transactions, or even to create authorization objects to modulate the state of their database based on user actions.


The following operations are implemented fully, with functionality that executes through the vchLedgerData data member of the Tritium Transaction class:

1. OP_WRITE: Write a new state to a register address given as a parameter to the operation code.

2. OP_REGISTER: Create a new register on the network. It must contain a unique register address, claiming it for this signature chain.

3. OP_TRANSFER: Transfer ownership of a register to another signature chain, or to another register address. This is an important function for establishing the ownership of data by signature chain, and the supply chain that moves it from one owner to the next.

4. OP_DEBIT: Debit a token from a given Account Object Register. This is the commitment of funds operation that gives the recipient the ability to claim with a corresponding credit. The balance of the debit that can be claimed is determined by the percentage ownership displayed through the temporal proof.

5. OP_CREDIT: Claim a balance referencing the transaction debit that was used to commit funds to the given receive account. If a credit is claiming a debit fund from an account they are joint owner of through register chain, a temporal proof is required to satisfy the display of their ownership.


The method that processes the operation codes is called execute:

src/TAO/Operation/include/execute.h | 477 +++++++++++++++

This method is responsible for the changing of the states on the ledger level, as operations are instructions to the processing nodes to modulate the state of a register through global consensus. The operations and register layers are being designed to be processed on higher locking levels of the 3DC (namely L2), to ensure that transaction processing is broken up across multiple node layers which adds to our ability to scale the advanced contract processing.


If an operation code is followed by a validation script it will require the validation boolean logic to evaluate to true if an operation code is to be claimable as a proof. What this means is that a certain logic needs to be true for that operation to be claimed. An example would be, “Do not call me past 9:00 PM”, if one was to try and make a phone call the call would not be possible.

src/TAO/Operation/include/validate.h | 54 ++++++

A simple example of this would be relating to debits and credits, where one could put stipulations on the OP_DEBIT requiring the time to be of a certain point in the future. What this would result in is the OP_CREDIT satisfying this script by being submitted past the timestamp that was required. This allows one to program logic beyond the basic operation logic to create greater functionality and customization.


The Application Programming Interface will use what is termed JSON (Java Script Object Notation) to submit commands to the nodes that create these state changes in the register, resulting in program logic that gives us the ability to use advanced contracts.

The API will have two components, public and private.

This is important, as the public API will always be developed with public funds through the multiple Nexus Embassies, and provide the required functionality for public use. This will include most of the use cases and programmable logic.


The reason for this is for the integration of businesses that require some of their application logic to be more specialized as far as API functionality, due to the proprietary nature of their developments. This also becomes a “software-as-a-service” integration opportunity for an Embassy to generate additional revenue streams, in which the profits can be recycled back into the core development process.

Logical and Interface

The new Nexus Tritium Wallet is now in public beta. The launch of this has brought an incredible amount of feedback and bug reporting to improve the interface and logical layers. As many of you already know, we provide one common interface for such functionality, where any other distributed application developers will be able to develop their own.

The logical layer is where most of the processing gets done. It is an extended application space through the OSI.

It is important to understand this, because the idea of a blockchain carries many connotations that extend beyond just the ledger. It can coordinate many systems, have private networks that operate and state record off the ledger, access control schemes, state recording based on user actions, and the list can go on. We like to leave this area open for any new type of developers to extend their application space from the conventional OSI design.

What’s in Our Future?

As you can see from this blog post, most of the hard developing is now complete for Tritium. This means that we are in the stage of weaving together code over the network, establishing local databases to handle your sigchain and register indexes, and adding lower level RPC commands to interact with the Ledger, with the higher level API being the interface in the command set.

What does this mean?

Tritium will be released by the end of January, 2019. Yes — I said it — a timeline. As we have noticed over the last year, the removal of roadmaps and timelines did not do what was intended, it only created further uncertainty and rumors in the project. As we are moving into Chapter 3 of our history books with distributed Embassies, newer architecture, and distributed governance models, we felt it was appropriate to augment this with commitments from the development team to set and meet deadlines.

Until Next Time, My friends.



Follow Colin Cantrell’s Medium here.

View the original post here.

Nexus Tritium in Action

Nexus Tritium in Action

Photo © 2018 Monica Rose Photo


At the 2018 Nexus Conference, Colin Cantrell, Nexus Founder and Software Architect, gave a brilliant presentation explaining the latest developments of the Nexus Tritium protocol. Tritium is the first release of the Nexus Three Dimensional Blockchain (3DC), and will be followed by Amine and Obsidian. He explained the necessity of each layer of the Tritium software stack (Network, Ledger, Register, Operations, Logical, API and Interface), their different functions, and gave a deeper explanation of the Lower Level Library (LLL). Colin displayed some impressive benchmark tests comparing the Nexus Lower Level Database (LLD) read / write speed to Ripple Nu DB, Google Level DB and Oracle Berkeley DB (spoiler: Nexus tested faster than all). He also demonstrated a live, functioning demo of Tritium with the entire stack running, and introduced many business use cases for advanced contracts.


The 3DC and the Tritium Software Stack

The design of the 3DC and the identification of node roles enables different nodes to perform different processes in parallel. This fundamental quality lays the foundation for scalable advanced contracts. The software stack also enables developers from all levels of experience to develop on the layer that is most suited to them. Colin explained that the stack design was inspired by nature: “As we know nature grows out in layers. Matter has certain layers of responsibility, where simple protons, neutrons and electrons form together a simple atom. They then start to form covalent Hydrogen or ionic bonds and then form molecules that form tissues and organs”.

Colin also gave a deeper explanation of the Lower Level Library (LLL), a polymorphic (able to inherit a class from a base class) template library and the foundation of Nexus. He compared the significantly faster performance of the Lower Level Database to other databases used in Bitcoin (Berkeley DB), Ethereum (LevelDB), and Ripple (NuDB). He highlighted the importance for the fundamental layers (Network and Ledger) to scale, as it supports the scalability of all the layers built on top (Register, Operation, API, etc.). The beauty of the LLL is that you can plug in any kind of processing system while maintaining high levels of scalability.

Here are the results of Colin’s 100,000 reads / writes benchmark test:

  • Nexus LLD: 0.818129 seconds
  • Ripple Nu DB 6.941530 seconds (Nexus
  • Google Level DB 7.714264 seconds
  • Oracle Berkeley DB 18.272793 seconds

Nexus Lower Level Database Performed:

  • 8x Faster than Ripple Nu DB
  • 9x Faster than Google Level DB
  • 22x Faster than Oracle Berkeley DB


Photo © 2018 John Saviano


The Lower Level Protocol (LLP) is a custom-made network protocol that is responsible for end-to-end communication between nodes. Colin explained why he created the LLP: “the way that sockets are managed has a large influence on the ability to handle a large amount of connections and requests per second”. A screenshot of a Lower Level Protocol test showed it running at 194,761 requests per a second with over 1,000 simultaneous connections. Such high levels of scalability have been achieved by squeezing computing cycles through fundamental simplicity. He reiterated the importance of reducing the routing complexity to O(1) through IP-Multicast, so that the addition of nodes to the network does not decrease its performance. This makes the network less vulnerable to eclipse attacks and allows for larger blocks as messages propagate faster. Additionally, the Location/Identifier Separation Protocol (LISP) decouples your address space from your input identifiers, allowing the traversal of NATs (Network Address Translation) and the encryption of all data, creating a fully encrypted peer-to-peer communication system.

The Ledger layer manages register ownership and is responsible for maintaining data immutability. Ownership of data is proven on this layer through a cryptographic proof provided by Signature Chains. The Ledger layer of the Nexus public blockchain is not a storage system like the Cloud, but is instead “an ownership tracking device that allows immutable ownership to be stored, that other private systems can connect into”. This begs the question, why not simply create a private blockchain? “Well, because then you have a private MySQL database.” With a public blockchain, the more people that contribute resources toward validation, the more secure it is. Colin went on to explain that some blockchains with more centralized consensus mechanisms, such as Delegated Proof-of-Stake protocols, may be vulnerable to Zero Day attacks.

Colin was especially excited to present the Register layer of the Tritium software stack. Registers are stateful objects owned by the signature chain that published it. They form a relational database model, where the relationship between different registers can be managed by cryptographic proofs on the Ledger layer below. Registers can be chained to one another with coupled validation logic in order to record and track change in ownership, or to create multi-signatory accounts. Registers currently fall into two categories: raw state registers that store raw bytecode that can be read or modified by authorized accounts, and object registers, which are predefined, serialized classes that update and change state through the Ledger. For example, object registers can store the state of an account’s token balance, which can be used as a proof of ownership in another register, such as an escrow. The Register architecture makes Nexus significantly different than any other blockchain. Using the Operation layer built on top of the Register layer, registers can be transferred, read, or modified in different ways. These two layers together create what Nexus has termed an Advanced Contract. Unlike Ethereum and most other smart contract implementations that are stack-based and use a large number of operations, registers are very efficient, as accessing the value of a register is an order of one O(1), because its exact index is known.

While other smart contracts are executed by the nodes on which they reside, often requiring a specialized compiler and interpreter to execute the contract, advanced contracts can use the Operations layer to perform predefined operations on the registers. Additionally, distributed applications can be written and executed on clients computers, using raw state registers to store data. Operations are byte-code functions that change registers from one state to another. For example, a DEBIT will change the state of an account balance if authorized to do so. Likewise, a receiver will use this temporal proof to CREDIT their account by way of another state change. Colin explained how validation logic could be created by users to set parameters, i.e. escrow functions, and emphasized the importance of standardizing operations and registers through an open process to define secure and efficient logic. To that end, Colin welcomed all to participate in the working groups to help shape the standardization process, like an Internet Engineering Task Force (IETF) for blockchain.

Application Programming Interfaces (APIs) allow easy, high-level interaction with the internals of a system. Nexus plans to make integration with blockchain technology seamless by abstracting the OSI Application layer above the aforementioned layers through APIs. The Logical layer will handle the interpretation of API calls and will populate results to the end user on the interface. Meanwhile, the Application layer will do most of the processing and data handling. The Ledger will only be used for validation and authorization, i.e tokenization and other forms of ownership. This allows developers the freedom to build their own applications at the logical/interface layers, while having access to the ledger and contract logic through JSON-APIs. This is important for many businesses, as they have sophisticated systems that already use many different APIs. There are many different use cases for a blockchain, which is why Nexus is focusing on scalability and ease of interoperability with old systems.


Tritium Live Demonstration

Colin’s live demo of Tritium showed how signature chains interact with one another and how the Ledger, Register, and Operations layers work together to create register chains and tokenized ownership. The Operation layer includes DEBIT, CREDIT, REGISTER, and WRITE operation codes. The Register layer used state proofs, ownership proofs, register chains, and account / token object registers. The demo showed the Ledger with two signature chains and demonstrated how a royalties payment could be executed in real time, based on ownership proofs represented by the corresponding token balance of the two signature chains. The token, called ART with a 100 ART max supply, was published to the Ledger. One signature chain was created with 50 ART and the other with another 50 ART, showing a 50-50 ownership. From there, one signature chain published metadata representing a song, with ownership assigned to the token object register. This allows a signature chain to prove partial ownership based on a token balance. This process takes about five database writes, which is a very low level of complexity, considering the LLD can handle hundreds of thousands of writes per a second. The next transaction demonstrated a debit operation from a native NXS object register, directly into the metadata register address, which then waited to be claimed. Colin explained that a CREDIT has to be claimed from a DEBIT, meaning that NXS will not be lost if sent to an invalid address. All tokens on Nexus are going to transfer as quickly as the NXS native token, taking only two operations.

Colin then demonstrated how the tokens are used as a temporal proof to claim 50% of the debit. He also attempted a double spend, to prove security, which failed, as the temporal proof had already been claimed by the object register holding the state of the balance of ART tokens on that signature chain. The owner of the other signature chain is then asked to provide their temporal proof from the state of their ART token balance to claim their 50% of the 20 NXS debit (ie. 10 NXS). They credit it to their account using this proof. This is all recorded on the Ledger, essentially serialized into byte code, and is interpreted by the operations engine by the method EXECUTE. Colin then demonstrated another double spend attempt that failed, to prove that the temporal proofs work only once. This is really important, as tokens can currently only be used to hold an ICO. However, tokenization can be used in many different processes to prove ownership, as they can prove a wide variety of chained events.


New Use Cases for Tokens

Colin spoke about the future of Nexus by introducing many new use cases with genuine utility, such as the tokenization of ownership, data, or assets. Anyone who attended the conference could see the passion and excitement in Colin’s voice as he presented these innovative solutions. Colin strongly believes that through music, blockchain technology will reach many different people. In the music industry, a large percentage of royalties goes to middle men, as do revenues in other industries go to third parties. As the demo showed, tokens can be used in licensing and in the use of copyrights, to provide artists and musicians the opportunity to earn money for their creations. Tokenization in the music industry will increase with importance, especially with the new Music Modernization Act. Now, a music subscriber could make a debit by paying a license fee once a month that would be split, based on the token ownership. It is important to note that the tokens are transferable while also retaining their utility in providing temporal proofs to the Ledger. This will allow an artist to crowdfund their new album by selling a portion of their tokens to the public. These tokens could then be sold on an exchange, traded, speculated on, and also be used to receive royalty payments. This gives tokens real utility beyond value storage and provides artists a new way to connect with their fans.

Supply chain transparency could be created with ease by recording the change in state, as NXS moves between each level of the supply chain. Tokens could also be used for automatic budget allocation for revenue streams, creating layers of tokenized accounts, which would save a lot of resources that go to managing this manually. Across many industries, tokens could help fraud prevention, as tokenized revenue streams will create a transparent movement of funds. Colin explained that tokens could split rights between many different people in order to create joint ownership. For example, in the sale of a jointly owned house. Tokens could also support patent leasing. A group of inventors could create tokens to distribute to investors, without the need for legal paperwork. Colin affirmed that “you don’t need a court, as crypto is the court”. The investor only has to prove that they hold the tokens to claim their percentage of the available dividend. Likewise, tokens could be used to represent shares of a company. A certain percentage of the revenue stream could then be allocated to the token holders, so that the dividends disperse automatically. A token split could also be utilized between a car dealership and manufacturer. The token distribution between the two would define the ownership of the revenue from a lease of the vehicle, allowing the automatic clearance of the finances and frictionless payout of revenue.

A further example was for the distribution of donations to nonprofits to prevent internal embezzlement, and the inefficiencies of administrative and managerial cost. Tokenization could make charitable donation distribution just and transparent, ensuring that a definite % goes to the people in need. Colin also explained how registers, debits, and credits could form the foundation of a decentralized exchange. For example, a seller could put up an order on Nexus, as an exchange object, a debit for 50 ART requiring a 10 NXS debit to this register, to allow a credit based on that temporal proof. Once both debits are fulfilled, the 50 ART would be unlocked for credit to the new holder, along with the 10 NXS to the new owner. Arbitration triangles could also be created, using multi-signature contracts with three signatories, but only two required to unlock funds. The arbiter or neutral party could be a shipping company, who could resolve any dispute between buyer and seller. The arbiter would only have power if there was a disagreement. This would provide safety in escrow services, and prevent the risk of deadlocks in case one signatory doesn’t agree with the other. Colin further explained that tokenization will allow the creation of distributed autonomous organisations, through token votes, where tokens could be used as proofs for vote weights in such a DAO. He ended his excellent presentation with a long awaited demo of the new wallet.

Most companies are in the early days of understanding how blockchain technology can help them, and it’s important to educate them on what blockchain can and cannot offer. Some companies are already aware of the potential use cases of blockchain technology for their business model, but are finding limitations posed by other protocols, like the scaling issues of the Ethereum Smart Contracts Platform. The business development team helps businesses discern what they need from a public blockchain versus what can be accomplished with a public-private hybrid system, and welcomes anyone who thinks they could benefit from the technology to contact them.


Watch Colin’s Full Presentation

The New Tritium Trust System: Wallet – REQUIRED Update

The New Tritium Trust System: Wallet – REQUIRED Update

The New Tritium Trust System Our Community Has Been Waiting For!

Colin has released a new version of the QT wallet with a re-vamped staking system. This update is REQUIRED by 09/14/2018 19:11:00 GMT -7 to keep your wallet running on the main chain. If you don’t update by then, your wallet will simply stop syncing, but your funds are safe. Just update as soon as you are able.

  • Read Colin’s Blog to find out more about the update:
  • Download the new wallet from Github:
    • Linux, .exe, and .dmg bins are all compiled!

If you are upgrading from or earlier, this version will re-index your blockchain database the first time it runs. The process will take a while, up to 5-10x the normal load time depending on your hardware. Let it load, then let it sync completely. You can also use the bootstrap to speed up the process.

  • Re-indexed database bootstrap is available: > Get Nexus > Recent Database
  • Directions:

After the initial load, it has been reported that the wallet starts within just a few minutes!

Upgrade Process:

  • Backup your current wallet
  • Exit current wallet
  • Download nexus-qt.exe for Windows, nexus-qt.dmg for Mac
  • Run the new executable instead of the old one

*If launching Nexus from the Spotlight “cmd space” you may get an error about your Mac version. Please go into the finder and on the left tab is a “Devices” section. Under “Devices” you will see “Remote Disk” and “nexus-qt”. Launch nexus-qt.

If you need assistance, please join our support channels.

  • Slack #support:
  • Telegram:

UPDATE (Edited) 9/14/18: 

Nexus Wallet is released for Windows and MAC:

If you experienced issues with your wallet syncing after the 2.5 update, please update to the RC-2 branch by downloading the new .exe or .dmg file from Github. You do not need to update if you did not have any syncing issues:

The TAO — Tritium Development Update #1

The TAO — Tritium Development Update #1

This blog begins a wonderful series of events that record the development of the TAO. As many already know, this stands for Tritium, Amine, and Obsidian representing major version 3.0, 4.0, and 5.0 respectively.

Some on topic but slightly tangential reasoning behind the names of the TAO.

  • Tritium is the third isotope of hydrogen (hydrogen-3)

  • Amine is the base for all amino acids. It is also a molecule consisting of 4 parts. Catching my drift now?

  • Obsidian is a volcanic glass that was used as an instrument in prehistoric surgery that can be made sharper than steel. It ranges in the 5’s on the Mohs Scale.

Correlations anyone?

Anyhow, my reasoning for these timely blogs is to give the community better information regarding what has been done since the last blog post. I’m going to start the standard here with dumping a “git pull origin master” from the head commit set back exactly to the date of last blog. This will — you know, let the code speak for itself.

.gitignore | 2 +-
Dockerfile | 100 +
config/.aliases | 31 +
config/.cshrc | 1 +
config/docker-run-tritium | 23 +
config/nexus.conf | 4 +
config/run-nexus | 7 +
contrib/ | 43 +
docs/.gitkeep | 0
docs/ | 68 +
lisp/.gitkeep | 0
lisp/README | 48 +
lisp/RL | 83 +
lisp/ | 174 +
lisp/lisp.config.xtr | 111 +
lisp/ | 193 +
makefile.cli | 227 +-
src/LLC/hash/SK.cpp | 38 +
src/LLC/hash/SK.h | 587 +-
src/LLC/hash/SK/Keccak-compact64.c | 45 +-
src/LLC/hash/SK/KeccakDuplex.c | 22 +-
src/LLC/hash/SK/KeccakDuplex.h | 8 +-
src/LLC/hash/SK/KeccakF-1600-interface.h | 38 +-
src/LLC/hash/SK/KeccakHash.c | 8 +-
src/LLC/hash/SK/KeccakHash.h | 8 +-
src/LLC/hash/SK/KeccakSponge.c | 38 +-
src/LLC/hash/SK/KeccakSponge.h | 14 +-
src/LLC/hash/SK/brg_types.h | 25 +-
src/LLC/hash/SK/skein_port.h | 6 +-
src/LLC/hash/Skein3Fish/include/brg_types.h | 16 +-
src/LLC/hash/Skein3Fish/include/skein_port.h | 6 +-
src/LLC/hash/macro.h | 10 +-
src/LLC/include/key.h | 324 +-
src/LLC/include/random.h | 18 +-
src/LLC/key.cpp | 70 +-
src/LLC/random.cpp | 36 +-
src/LLC/types/bignum.h | 1219 +-
src/LLC/types/uint1024.h | 677 +-
src/LLD/templates/filemap.h | 66 +-
src/LLD/templates/hashmap.h | 60 +-
src/LLD/templates/journal.h | 10 +-
src/LLD/templates/key.h | 83 +-
src/LLD/templates/pool.h | 56 +-
src/LLD/templates/sector.h | 78 +-
src/LLD/templates/transaction.h | 24 +-
src/LLD/templates/version.h | 41 +
src/LLP/hosts.cpp | 16 +-
src/LLP/include/hosts.h | 12 +-
src/LLP/include/inv.h | 24 +-
src/LLP/include/legacy.h | 354 +-
src/LLP/include/network.h | 103 +-
src/LLP/include/permissions.h | 10 +-
src/LLP/include/version.h | 45 +
src/LLP/inv.cpp | 103 +
src/LLP/legacy.cpp | 684 +-
src/LLP/network.cpp | 174 +-
src/LLP/socket.cpp | 245 +
src/LLP/templates/data.h | 157 +-
src/LLP/templates/server.h | 334 +-
src/LLP/templates/socket.h | 124 +
src/LLP/templates/types.h | 444 +-
src/TAO/API/rpcdump.cpp | 234 +
src/TAO/API/rpcserver.cpp | 3551 ++++++
src/TAO/API/rpcserver.h | 77 +
src/TAO/Ledger/checkpoints.cpp | 104 +
src/TAO/Ledger/difficulty.cpp | 470 +
src/TAO/Ledger/global.cpp | 287 +
src/TAO/Ledger/include/block.h | 57 +
src/TAO/Ledger/include/checkpoints.h | 63 +
src/TAO/Ledger/include/difficulty.h | 57 +
src/TAO/Ledger/include/global.h | 370 +
src/TAO/Ledger/include/prime.h | 51 +
src/TAO/Ledger/include/sigchain.h | 136 +-
src/TAO/Ledger/include/supply.h | 76 +
src/TAO/Ledger/include/time.h | 77 +
src/TAO/Ledger/include/trust.h | 197 +
src/TAO/Ledger/prime.cpp | 128 +
src/TAO/Ledger/supply.cpp | 181 +
src/TAO/Ledger/trust.cpp | 1063 ++
src/TAO/Ledger/types/block.cpp | 315 +
src/TAO/Ledger/types/include/block.h | 312 +
src/TAO/Ledger/types/include/data.h | 78 +
src/TAO/Ledger/types/include/locator.h | 109 +
src/TAO/Ledger/types/include/state.h | 124 +
src/TAO/Ledger/types/include/transaction.h | 66 +
src/TAO/Legacy/crypter.cpp | 150 +
src/TAO/Legacy/db.cpp | 576 +
src/TAO/Legacy/include/crypter.h | 113 +
src/TAO/Legacy/include/db.h | 345 +
src/TAO/Legacy/include/keystore.h | 199 +
src/TAO/Legacy/include/wallet.h | 768 ++
src/TAO/Legacy/include/walletdb.h | 192 +
src/TAO/Legacy/keystore.cpp | 218 +
src/TAO/Legacy/types/address.cpp | 127 +
src/TAO/Legacy/types/enum.cpp | 180 +
src/TAO/Legacy/types/include/address.h | 140 +
src/TAO/Legacy/types/include/enum.h | 226 +
src/TAO/Legacy/types/include/inpoint.h | 82 +
src/TAO/Legacy/types/include/merkle.h | 74 +
src/TAO/Legacy/types/include/outpoint.h | 144 +
src/TAO/Legacy/types/include/script.h | 463 +
src/TAO/Legacy/types/include/secret.h | 100 +
src/TAO/Legacy/types/include/transaction.h | 380 +
src/TAO/Legacy/types/include/txin.h | 165 +
src/TAO/Legacy/types/include/txout.h | 166 +
src/TAO/Legacy/types/outpoint.cpp | 46 +
src/TAO/Legacy/types/script.cpp | 1569 +++
src/TAO/Legacy/types/secret.cpp | 85 +
src/TAO/Legacy/types/transaction.cpp | 971 ++
src/TAO/Legacy/types/txin.cpp | 93 +
src/TAO/Legacy/types/txout.cpp | 93 +
src/TAO/Legacy/wallet.cpp | 1697 +++
src/TAO/Legacy/walletdb.cpp | 458 +
src/TAO/Operation/include/execute.h | 191 +
src/TAO/Operation/include/operations.h | 83 +
src/TAO/Register/include/object.h | 105 +
src/TAO/Register/include/state.h | 154 +
src/Util/args.cpp | 32 +-
src/Util/base58.cpp | 226 +
src/Util/config.cpp | 16 +-
src/Util/debug.cpp | 6 +-
src/Util/include/allocators.h | 6 +-
src/Util/include/args.h | 26 +-
src/Util/include/base58.h | 225 +
src/Util/include/base64.h | 24 +-
src/Util/include/config.h | 14 +-
src/Util/include/convert.h | 46 +-
src/Util/include/debug.h | 6 +-
src/Util/include/hex.h | 34 +-
src/Util/include/json.h | 18912 ++++++++++++
src/Util/include/mutex.h | 6 +-
src/Util/include/parse.h | 30 +-
src/Util/include/runtime.h | 46 +-
src/Util/include/sorting.h | 6 +-
src/Util/include/version.h | 37 +
src/Util/macro/header.h | 27 +
src/Util/templates/containers.h | 10 +-
src/Util/templates/mruset.h | 6 +-
src/Util/templates/serialize.h | 314 +-
src/main.cpp | 893 +-
tests/smoke/ | 95 +
tests/smoke/examples/nexus.conf.publictestnet | 12 +
tests/smoke/ | 5 +
makefile.unix => tests/smoke/makefile.unix.test | 125 +-
tests/smoke/ | 5 +
tests/smoke/ | 265 +
tests/smoke/ | 5 +
tests/smoke/ | 5 +
tests/smoke/ | 7 +
tests/smoke/ | 21 +
tests/smoke/ | 5 +
154 files changed, 43266 insertions(+), 4466 deletions(-)

Lots of file dumps, collectively its an addition of ~ 39,000 lines of code. I’ll explain why there’s so much new code, and what’s happening under the hood as we speak. Bear with me if you’re not very technical, or skip to the end since I’m going to get fairly detailed.

Let’s start with the Network Layer:


The network as you all most likely know is powered by the Lower Level Protocol. The Lower Level Protocol (LLP from here forward) is a polymorphic template protocol. Yes that’s a mouthful, but it’s just another way for us coder people to say, “I build this template once, and I can use it for anything”. This is called good code design, since, you end up needing less endlessly repeating sequences of the same code with slight alterations. In this case, you drop in a new packet type, write a new ProcessPacket method, and boom you have a new protocol.

So what makes this special? It’s because most servers on the internet have a very hard time scaling. They usually follow the blocking one per thread model, using socket selects, or even operating on a single thread asynchronous model like node.js and boost asio. Now this is important to understand, because asynchronous models have been touted as being far more scale able — this is true, but not to be mistaken for how this can be implemented. When you hear people say Node.js scale able elastic computing front end, they mean asynchronous sockets since Node.js uses Google’s V8 Javascript engine, and allows sockets and Javascript on the server side (this usually happens on the client side).

Anyhow, let’s continue. The LLP is also a multi-threaded asynchronous socket packet handler… this means that any user wanting to work with the LLP can create literally any protocol they want, and are always going to have the trusty, well tested, server back end. The LLP is now completely absolved of any boost dependencies, part of the new coding standards in this project. The reason for removing all boost is that it is quite a heavy framework that was developed for the C++98 veterans, to do nice simple things that the STL couldn’t do. Now, C++11/14 standards contain a lot of the boost necessities in STL which means that all boost code can be removed (phew).

So enough on that, let’s see some results from my latest stress test:

This is a single computer, 1000 connections, and 144,485 requests per second. This performance is well within requirements for VISA scale abilty (20k / second peak). It is very important for these base layers to not become bottlenecks, so there has been a lot of attention given to the LLP over the course of this week.


Now we start to get to some fun stuff, the Ledger! As you can see from the above “git pull origin master”, there are a lot of files. Each one, as you will notice, is organized very neatly based on its function, and put in its proper namespace.The Ledger code consists of block validation, transaction validation, and basic lower level ledger data scripts to handle register reads and writes. Most of the legacy code is implemented and operating in order to allow backwards compatibility with the Legacy UTXO sets — while allowing a transition time into the more efficient Tritium Transaction.

There are two block structures here in the ledger layer, Legacy and Tritium. Legacy blocks push the heavy block data and transaction data coupled to a 2MB limit every 50 seconds, newer lighter Tritium blocks only retain the transaction hash, which means that maximum transaction size now goes down to 64 bytes. Since the transaction is broadcast over the LLP to the entire network, and it operates efficiently, transaction processing can be done mostly in the time while waiting for the block. This means that transactions locked into the memory pool, can be cached and verified and easily connected when the block comes, requiring little processing power, and blocks that can contain up to 32,768 transactions every 50 seconds. This amounts to a maximum transaction rate of 655 / second assuming a 42 Kb/s data rate.

This feature will is a stepping stone towards a 3DC simulating a single L1 state channel.


Now we start to get above the ledger abstraction, and into new territory. Registers are sitting on top of the ledger, having identification tied from the ledger. The ledger scripts are the interface that allow registers to be defined, and permissions of each to be granted. The two types of registers that exist as of now are state and object registers.

A state register is the raw bytes of data that represent the state of whatever object one defines. An object register contains more type-safe data sets. What this means, is that an Account will be an object register to store the state of your balance. It goes similar to this:

std::vector<uint8_t> vchIdentifier;

uint64_t nBalance;

The account’s address is actually the register’s address, so that if a user is to commit a DEBIT op to that register address, the owner of the address would be required to issue the CREDIT of the according balance. The vchIdentifier is what holds the unique type of account this is, which in other words means the ability to create tokens that transfer with the same efficiency as NXS. This is just the beginning, I’ll get more technical on the scope of these layers and how they weave together in blogs following this one.

src/TAO/Register/include/object.h | 105 +
src/TAO/Register/include/state.h | 154 +


The operation layer gives context to the register layer. To the ledger, a transaction is just raw bytes like a packet is to a network router, but it isn’t until you get higher up the stack that context is given to that data. This is one of the methods that has been developed to scale efficiently, and as you can see, every layer needs to be well thought through, interfaced, and connected together seamlessly. If the lower layers create bottlenecks it affects all the layers above it.

The following operations have been defined:

OP_WRITE = 0x01,
OP_READ = 0x02,
OP_ACCOUNT = 0x20,
OP_CREDIT = 0x21,
OP_DEBIT = 0x22,
OP_BALANCE = 0x23,
OP_EXPIRE = 0x24,
OP_CREATE = 0x25,

These represent basic byte code logic sequences that execute to change the states of object registers through verification of other nodes. This list will continue to grow, for now, the simpler with the highest functionality, the more efficient and scale able.

src/TAO/Operation/include/execute.h | 191 +
src/TAO/Operation/include/operations.h | 83 +

I’ll go into more details on my next blog post exactly how these weave together to make for very interesting use cases with Nexus Contracts.


The API, ah yes, what many people are waiting for. This operates on a HTTP-JSON server that allows anyone to create contracts without needing to learn all the lower level code that drives the entire engine. The message format will be broken into many different industry specific API’s, and be powered by an HTTP-LLP server.

As you could see from the above LLP test results, the API will be able to handle quite a lot of load even operating on a single node. Now since the network is Peer to Peer, this means that an API instance will be running on any node that decides to deploy that as a service.

I will go into more details on the specifications of the API and message format in the next blog post.

Until Next Time:

I hope this was an informative blog update— in light of being able to communicate in a more technical nature the developments of the TAO code base. I will continue to share benchmarks of tests, simulating high throughput transaction environments, and more load tests of each layer as they are woven together to be ready for the public testnet deployment.

I look forward to the working groups this year, to get our first standardization process complete — and prepare for main net deployment.