Ethereum and NEM: Two Different Approaches for Blockchain Application Development

After working on Ethereum for a while, I recently got a chance to take a look into NEM. And I see two very different approaches they are taking when providing a blockchain environment for building applications. In this article I will put them down and do a quick comparison between them.

Overview of NEM

There is much more information on Ethereum in the market. Therefore here I am giving a quick overview of NEM.

NEM is a home-grown blockchain technology, which can be deployed as both public and private ledgers. Here we focus on the public ledger.

NEM comes with a native currency XEM. Like ether in Ethereum, XEM is used when one uses services on NEM. XEM is of fixed supply, and the incentive of block-building (harvesting, loosely equivalent to mining in ethereum) is the transaction fees when NEM services are consumed. NEM also comes with a different consensus algorithm called Proof of Importance, which adds certain factors when considering one’s chance to harvest. In general it is also a permissionless approach just as ethereum (and bitcoin), that everyone can participate into the block-building.

How they provide an environment to application development is of my interest. NEM is taking a different approach from Ethereum. While Ethereum is a platform which allows application developer coding on the blockchain, NEM provides certain useful and handy services that developers can access at any time.

Here are some facts when comparing these two blockchain platforms.

Let’s go further into these two approaches on application development.

Ethereum: Platform for Coding

In Ethereum, developers have flexibility to code something new. While we can only code according to what Solidity and the opcode provide, from what we have seen in the market so far, there can be many types of applications in this platform.

We can easily find sample applications and make reference to them when we code (or learn to code). There are also some libraries created for specific purposes. As an example, Open Zeppelin (link) provides libraries for token and crowdsale. Most of these codes are made open and publicly accessible, and being used in many deployed contracts.

However, this is also where problems come. When we are using the code or libraries provided by third parties, it is our responsibility to make sure they do not come with problems, and we should have the knowledge to get rid of them. The recent overflow problem in ERC20 (link) already gives us good lesson. Simply copying code somewhere may cause big trouble, and sometimes we just overlook some latest good stuff (such as the use of Safemath in Open Zeppelin to address overflow problem).

Application architecture is something of concern. Contract is deployed as bytecode interacting with the blockchain directly, and the external world uses library interfacing this deployed contract. A complete application (we usually refer it “decentralized application”, dApp) is composed of at least two programming languages: a frontend one (e.g. JavaScript or Python), and Solidity the ethereum contract language. From architecture point of view it is a bit bulky, not to mention that Solidity as a language is still at her young age and we keep seeing evolvement (and changes).

NEM: Platform for Services

NEM is taking a different approach: while the bottom is still a public ledger, NEM provides certain useful and handy services that developers can consumes when they build their applications.

NEM must have done great study on the market need of services. Besides simple fund transfer (transfer XEM from one account to another), they bring in some unique and useful services such as multi-signature accounts, message encryption, notary service (Apostille), smart assets (Mosaics), and I am sure they will come up more when they see the needs.

This article does not go into detail on how these services work. You can find more and better information in NEM’s documentation.

While these services more or less can be implemented with contract codes on Ethereum (and some have been done already), NEM makes them available immediately, either with its wallet or through API. API (application programming interface) is no stranger to developers as applications nowadays require interfacing various services through API. Developer therefore does not need to reinvent the wheels, but simply picks the service they need, and uses it.

This makes the application architecture neater: developer focuses on the business logic, and the services are called (or consumed) when needed. This much more aligns to today’s development manner. Also, as these services are now maintained by NEM, it comes with assurance “to certain extent”. At least, when problems appear, we know who to blame.

This approach, however, comes with shortcoming. Developer can use only “what it is”. While NEM is building whatever possible to meet market requirement, there are always cases that existing services cannot meet developer’s need.

There is no room for contract-like programmability on NEM blockchain currently: no Solidity-like coding language. Everything on NEM today is built by NEM themselves.

What can developers do then? To certain extent they have to wait for NEM to release new on-chain features, or they build the “off-chain” services by themselves. Anything built outside the NEM does not come with the beauty of blockchain, and the public may question the level of assurance if they are not coming from NEM.


The following diagram summarizes the two different approaches in blockchain application development.

The application code developed is orange in colour. As seen in the diagram, in Ethereum the contract code is needed when interacting with Ethereum blockchain, while in NEM, several well-built services (such as multisig account, smart assets, etc) are provided by NEM platform and application developer simply calls these services.

If you are faimliar with terminology XaaS (X-as-a-service) in cloud, I can roughly say Ethereum a Platform-as-a-Service (PaaS), while NEM is more like a Software-as-a-Service (SaaS).

I believe these two camps are not born in competing each other: they just take two different approaches when using blockchain technologies in real life. Application developers, when they build their applications with blockchain capabilities, can now have a choice: they can either build some on-chain business logic on Ethereum, or off-chain application simply leveraging the capabilities NEM is providing.

Written by

Happy to share what I learn on blockchain. Visit for my works. or reach me on

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store