Nexus Wallet Development Update – Private Beta 1.0

Nexus Wallet Development Update – Private Beta 1.0

The Nexus Wallet Private Beta 1.0 launches tomorrow, on August 31st, 2018!

The alpha phase was very productive with the front-end and back-end developers testing major features of the new interface and fixing the bugs that came up during this first round. “Alpha has illuminated issues with our approach in a few key areas,” said Dillon Dugan. “This has resulted in the dev team reworking some of the logic on a few of the screens which has yielded a much better screen workflow.” The last merge from the alpha sprint will happen today, including a new alert system for errors and feedback in the send/receive NXS module.

Private Beta 1.0 will have 18 new testers, including six subject matter experts (SMEs). The SMEs will be set up in a full private test environment so that they can find bugs, make improvements, and then submit them to the devs. The group includes a seed node operator, miners, and original Nexus developers from the community. They will work directly with the other 12 testers to decrease redundancy of bug reports and distribute the scope of work. The Beta 1.0 group was chosen specifically for their range of skills so the team can get well-rounded feedback. A checklist of the basic functions that need to be verified has been created so that the group can confirm that all of them are working the same way and without issues for everyone. Additional issues, feature requests, and design suggestions can also be submitted.

Phil Swazey, the Nexus satellite expert, is expanding his role as Program Manager to oversee the process. He will be working closely with each of our developers to facilitate communications with Anastasiya and continue providing development updates to our community. Nick Earl, aka @BibbityJibbity, will lead the organization of testers in a private Slack channel. We look forward to our ongoing collaboration with our community and appreciate everyone’s feedback on the new Nexus wallet!

Nexus Partners with BitSpace to Advance Blockchain Technology in Space

Nexus Partners with BitSpace to Advance Blockchain Technology in Space

Scottsdale, Aug. 30, 2018 (GLOBE NEWSWIRE) —  Nexus, a cryptocurrency and blockchain enterprise is excited to announce its partnership with BitSpace, a technology company that specializes in blockchain and exponential technology. The partnership is focused on supporting decentralized internet access and associated opportunities for people throughout the world through the use of Nexus advanced blockchain technology, satellite initiatives, and BitSpace international connections. Both companies are committed to the decentralization vision, where all individuals can come together to create and use new distributed systems that better serve humanity in day-to-day life.

“I’m happy to see BitSpace looking ahead to find solutions in space that can solve problems here on earth. We look forward to working together to open up more opportunity in Europe and Low Earth Orbit.” said Colin Cantrell,  founder and chief architect of Nexus.

BitSpace has created a community platform in the Nordic region and will work with Nexus to arrange mutually beneficial community events and  educational conferences. They also aim to explore opportunities to connect and integrate businesses pursuing blockchain and space technologies.

Nexus and BitSpace intend to collaborate with American and Norwegian Universities to support academic research with the goal of advancing decentralized technology and associated space applications.

“We believe that Space Technology combined with Blockchain represents an exciting opportunity to decentralize the future and we are very excited to discover this realm with Nexus Earth,” said Manuel Lains, CEO BitSpace.

About Nexus:

Nexus is an innovative open-source blockchain technology and digital currency designed to improve the world through advanced peer-to-peer networks. Nexus focuses on solving the current challenges of speed and scalability in the blockchain industry and provides world-class quantum resistance through its many innovations. Enabled by its partnership with Vector Space Systems, we aspire to combine blockchain technology with ground-based MESH networks and satellites to facilitate the formation of a decentralized and distributed internet.  Nexus will enable people to take control of their personal and financial freedom, empowering humanity in the process. For more information and to see how you can help build the future, visit

About BitSpace:

BitSpace is a technology company that specializes in blockchain and exponential technology. Their headquarters is based in Oslo, Norway and they are now expanding their operations internationally throughout Europe. With more than 20 years collective experience within the blockchain sector they allocate their resources towards community growth, incubation, and software development. The mission at BitSpace is to help build the future through emerging technologies that include Blockchain, Artificial Intelligence, Space, and Virtual Reality. To find out more you can visit

An Unexpected Scalability Solution: LISP and Nexus

An Unexpected Scalability Solution: LISP and Nexus

A young engineer, Colin Cantrell, was on stage outlining the next evolution of blockchain technology at the 2017 Nexus Conference in Aspen, Colorado. As he stood on the stage, one of the biggest challenges facing the industry was scaling for mass adoption. Colin was presenting a new multi-dimensional chain that would make this a possibility, but there was still a question of how exactly nodes could scale on the network level. An audience member, Dino Farinacci, raised his hand, “Have you considered using IP multicast?” Colin had not, and they decided to meet after the conference to discuss this scaling solution that would not only greatly enhance the architecture, but also create a much needed level of stability at the foundational network level. That’s how the partnership between Nexus and LISP was born.

Dino Farinacci is a network engineer, the founder of, and one of the original creators of the internet who worked as a Fellow at cisco Systems. He met Jon Hazell, a Nexus advocate and filmmaker, on a train, after attending a Bitcoin conference in 2014. Three years later, Dino was invited to the first Nexus Conference to present the history of networking. The event brought together some of the greatest thinkers and innovators in the world and has spurred a new era in the evolution of Nexus technology. As serendipitous connections go, this one led to a powerful breakthrough for both projects.

Dino teaches the Nexus team about LISP

To understand the benefits of this scaling network solution, we have to look at the difference between how the internet runs now, and what modifications are necessary to enhance its structure for newer applications. Most people assume the Internet already scales, but neglect to realize that when high capacity applications are in use, you load up the lower layers of the Internet infrastructure, which slows down message routing by using more resources. Did you know at the current rate of adoption of devices (cell phones, wireless earbuds, ipads, etc.) we have already run out of usable IP addresses?

IPv4 vs IPv6

The current internet infrastructure runs on the IPv4 system which can handle 4.3 billion IP addresses, while there are 8 billion possible users that own multiple devices. Designed in the early 1990s, IPv6 has 4 times the address space of IPv4, where every particle on earth could be addresseable. After all this time, the Internet is still transitioning from IPv4 to a dual-stack system, to ultimately IPv6. In the meantime, LISP can be used to get end-systems IPv6 addressed by using its overlay technology.  This will allow more devices to be connected even when the core network underlay is not IPv6 deployed.

Unicast vs. Multicast

In Unicast flood networks all nodes must process and then relay information individually. Think of how you communicate with your friends about a concert you’re all going to. You can text the event information to a friend, and he texts the next friend, and he texts his girlfriend, etc., until everyone has the correct information. This uses more resources, and slows down information flow, but is extremely useful in cases like streaming movies where each user needs to have individual control over when to stop or pause. Multicast is akin to group text messages where you can text all of your friends at the same time. This increases speed and creates parallelism as the message is broadcast to all the relevant nodes at the same time, while preserving global consensus.


LISP is the Locator/ID Separation Protocol that separates IP address semantics into a fixed identity address (EID: End-point ID) and a locator address (RLOCs: Routing Locators).  Instead of your identity changing each time you move your device, it stays fixed and obfuscated, allowing everything to run more smoothly. Comparing this to blockchain, your EID basically becomes the “trust key” for your identity.  Your EID address is the same address you would be using today on your device, but the address can remain assigned to you independent of how and where you connect to the network. Instead of running on the IPv4 underlay, LISP send packets through on the IPv6 overlay, which adds another level of cryptographic security to the information. Most importantly, it creates a distributed topology regardless of connection method or location.

From Chance Meeting to Today

Colin and Dino have spent the first part of 2018 integrating the LISP architecture into the Nexus network and testing the Nexus nodes on the overlay. Nexus is currently developing its Tritium Software Stack: the first on-chain scalability upgrade to the Nexus blockchain. While scaling on the ledger level is crucial, network scalability plays just as an of important role. With the two protocols working seamlessly together, mass adoption becomes an attainable goal. This is the type of breakthrough that can only happen when people come together and collaborate to build a better future together.

Dino and Colin look forward to introducing the world to the new developments between network and ledger scalability, and the possibilities that arise when Nexus and LISP combine forces at the 2018 Nexus Conference.  Please join us as we build the future together!

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.





Nexus Earth Newsletter August 2018

Nexus Earth Newsletter August 2018

It’s been a busy month as we’ve been preparing for launches both near and far.  As we reflect on our vision and evolution it’s important to revisit our values. We have a renewed focus on getting back to our roots: decentralization, connection, and code.   In order to embrace these roots, we are focusing in and reformatting the 2018 Nexus Conference with an emphasis on education, networking, code, and connection. This revised conference strategy will ensure that the conference is highly productive in advancing our code and subsequent use cases.

Our collective travels over the month have engaged our community in London, identified new potential partners in Europe, solicited insights from the IETF, and furthered our existing partnership with SingularityNET.  The core of Nexus is connecting with humanity and we look forward to sharing some of these connections and partnerships in the near future. Please join us at our 2018 Nexus Conference!

Nexus Wallet Development Update

The new Nexus Wallet is officially in alpha! Join us for the journey as we get closer to the big reveal:

Satellite Update from “Satellite Guy” Phil Swazey

The NXS1 cube satellite (cubesat) is progressing well towards its March 2019 goal date. Vector’s estimated launch date has changed from October 2018 to March 2019.  All of the satellite components have been procured and assembled as a flight engineering model, pictured below. The engineering model of the satellite is now undergoing integration, verification, and validation testing to verify that the components are all operating up to specifications. Once the integration testing is complete the flight model of the satellite will be assembled and placed in a vacuum chamber for further testing to simulate the space environment. Upon completion of testing the satellite will be packaged and transported to the United States from the manufacturer’s (Space Inventor) facility in Denmark .

Nexus has completed the process of identifying all of the components for the building of a ground station to communicate with the satellite once it is in its operational orbit. Approval for the funding of the ground station is currently underway. The ground station will become a key component for the operations and maintenance of the NXS1 as well as the NXS2 satellites.

The satellite components in assembly

Nexus: Coming Back to Our Roots

“The spirit of Nexus is freedom, love, and self expression” – Colin Cantrell

Decentralization and connection: the two evolutionary pillars that have sprung up from the blockchain revolution.

They represent the free flow of energy through consciousness: the transfer of information between humans, a transfer of data between machines, the relation of events, and the movements of Nature. Everything in the Universe is interconnected. We strive to find acceptance and to be a part of the flow, to feel at home wherever we go, to get the things that nurture our mind, body, and soul.

This is the direction humanity is moving in and it is clearly seen within the emerging blockchain and cryptocurrency industry. Originally created by a group of pioneers, the technology was built and given to humanity to grow and develop. We believe in the vision of people coming together with their individual skills and talents to collaborate and be a part of something bigger than themselves.

The Nexus community is at the forefront of this movement. Full of passion, curiosity and a keen sense of justice, we are constantly searching for better ways to connect. Yet no journey is without its challenges and lately we have struggled to connect while staying decentralized. Building new systems and structures requires experimentation, drive and collaboration, but it is easy to default to hierarchies and give away our power because that is what humanity has been taught to accept for centuries. That is not the way any longer!

We are free and we are powerful. We all see a variation of a new world where no one is boxed into systems that take away our voice or tell us that our creative spirit is not aligned with some corporate agenda. Self-expression and spontaneous self-organization is at the core of the Nexus philosophy and that is the way forward.

In that spirit, The US Nexus Embassy will be going through a lot of changes in the next few months and focusing on becoming community-centric once again; the root of the blockchain decentralization movement. We are also restarting up our Nexus bounty program. For all those who want to be involved and come up with creative projects, please join our communities on Telegram and Slack. All writers, artists, developers, meme masters, and translators are welcome!

As we collect ideas and suggestions, this incentive program will continue to evolve.

Telegram Announcements:



Nexus Conference 2018 Update

In the interest of realigning with our core values, getting back to our code development and community roots, Nexus is evolving the 2018 Nexus Conference to support our overall refocus efforts. We are focusing in on accommodating 300 attendees for a more intimate networking and educational event with increased focus on new code demonstrations including LISP integration and advanced contracting. We will continue to feature many of our amazing speakers sharing insights into the future of technology, with an increased focus on releasing the current state of our code, and progress to create a distributed internet in space. With less overhead and more focus, we can introduce new concepts to help build out those core values: enter Nexus working groups.

An Introduction to Nexus Working groups:

Individuals are invited to come together in Scottsdale to collaborate in the development of the Nexus stack via Nexus working groups. Once the working groups meet in person they will continue their communication and build-out through online interaction. Nexus working groups will be modeled after those of the IETF (Internet Engineering Task Force). Those that participate will have the opportunity to build out the model for how the working groups will operate. The future vision of working groups at Nexus is to have them align and build on a range of topics. If you would like to collaborate in building out the Nexus stack via working groups, or learn more about them, please join us at the 2018 Nexus Conference! Working groups will take place on Friday, September 21st. For more information on Nexus groups you can also join our telegram channel

Colin, Brian, and Dino at IETF Montreal

Colin Cantrell, Brian Smith, and Dino Farinacci ( attended the Internet Engineering Task Force (IETF) in Montreal, Canada, in mid July.  The IETF meets three times per year, bringing together pioneers of the internet to develop protocols.  Dino has been attending IETF for many years, while this was Colin’s second visit and Brian’s first. Hot topics at the meeting included how to scale blockchain, how the IETF could help crypto-currency designers, and how  overlays can help distributed ledgers.

Brian and Dino attended the Sunday night tutorial on ILNP (an alternate way to do locator/ID separation for LISP), and found it useful to compare the pros and cons between ILNP and LISP. Both Colin and Dino presented at the LISP Working Group. Dino presented the ‘draft-farinacci-lisp-telemetry’ draft that Tritium will use to get more underlay measurements of the network when selecting peers. Additionally, he presented an update to ‘draft-farinacci-lisp-ecdsa-auth’ which is being used in IoT environments. Colin gave an update on ‘draft-farinacci-lisp-decent’ (a design for a decentralized mapping system) and shared some new ideas about how a pull-based mapping system could be used by doing algorithmic mapping from an EID (end-point ID) being registered/requested to the map-servers that will be used to shard the database. Additionally, Colin presented high-level ideas on how the DLT can use LISP crypto-EIDs as well as how LISP could use the DLT to validate mappings and store EID allocations. Good feedback was received on the presentations including lots of questions. Updates to all specs presented will follow and action items were put in place to present at the fall IETF in Bangkok.

Colin and Alex visit SingularityNET in Hong Kong

Colin, Alex, and Jules met with Ben Georterzel of SingularityNET to thoroughly explain the scalable technology of LISP and the 3DC. The developers of SingularityNET and Nexus will first collaborate on the research and development of reputation systems, which are imperative to the security of the Nexus Earth network and to the future decentralized marketplace for Artificial Intelligence. Nexus also envisions that different reputation systems could be built to suit the requirements of specific community and commercial applications, to serve resource sharing ventures that require data to be verified by an immutable consensus mechanism. The teams discussed many topics, including how AI could be employed as agents to detect abnormal behavior of nodes on the Nexus network, i.e. the creation of numerous signature chains for the purpose of making an attack.

Team Hire: Front-End Software Engineer

Demorio (Demo) Fluker joined the Nexus development team in July. He has always been fascinated with the inner workings and compositions of things. He started with PC building and quickly escalated to building applications and websites. With the decision to finally turn that fascination into a career, he attended Woz U, graduating in 2018 as a certified web developer. Demo aims to  bring his creativity, talent, and positive energy to Nexus as a front-end software engineer. In his spare time, Demo enjoys producing instrumentals and songs in his home studio.

Community Contributions

Nexus Prime GPU Miner (v1.0) Released

One of the most fascinating things about the Nexus blockchain is that it incorporates three different channels to validate data: a proof-of-stake, a hashing proof-of-work, and a prime proof-of-work channel. For over a year, our community has tried to solve a dilemma with the prime channel: our previous miners were too inefficient to compete with a monopolizing force. Now, thanks to Jack McGowen (@Blackjack) and Nexus Lover’s (@nobody) guidance, we have taken a crucial step in decentralizing the prime channel.

Full article:

Prime GPU Miner:

Lightpapers: The Nexus Tritium White Paper by Peter Keay

Pete Keay published another informative article on ICOAlert, a Lightpaper about the architecture of Tritium. Lightpapers are technical white papers summarized for crypto enthusiasts.

Read Pete’s Lightpaper on Tritium:

Nexus London Meetup

At the beginning of July, Colin, Alex, Scott, Brian, and Ajay met with some of the European Nexus community in London, organized by Jules (@jules). Many Polish members of the Nexus Community joined in, among others. The team then spent a week meeting with businesses in London working on new development opportunities and use cases, which will be announced in the near future.

Nexus in the Media

Colin and Colin on Decentralized Podcast from Sydney:

An Easy Intro to the Nexus Tritium Protocol, Sekigahara Research Group:

Libertarian National Convention Blockchain Panel with Colin Cantrell:

Houston, We Have a Solution: Blockchain in the Space Industry, Cointelegraph:

NEXUS|Nexus Cryptocurrency Review: NXS Coins:


Thanks to our community for continuing to evolve and challenge Nexus to be its best so that we can have the biggest positive impact, via this technology, possible. We look forward to getting back to our roots with all of you and refocusing our mission.

Lastly, we are very much looking forward to seeing you in Scottsdale next month at The Nexus Conference. This valuable exchange will provide many opportunities to expand our horizons and to personally interact to build the future together. See you there!

Thank you!

The Nexus Team