Blockchain, IoT, and the Future of Transportation: Understanding the Motoro Coin

View all articles

Decentralized vehicle rentals inspired the open-source blockchain IoT project, from which the utility coin Motoro has emerged. In the foreseeable future, the public smart contracts described below will be accessible through distributed app (ĐApp) interfaces. The startup VIKING GARAGE already provides access to better motorcycle rentals in Europe and Southeast Asia. The stories witnessed there have been driving the research and development of an open protocol for peer-to-peer motorized machine rentals through blockchain technology.


Technical conferences are always an intellectual feast. Massive energy is focused on improving humanity. The creativity spent on imagining a better future never disappoints. But there are also cautions against technology going awry, like when Stephen Hawking recently warned that AI may become our doom. This contrast definitely paves the way for interesting discussions during Uber rides.

The flip side is brighter. We now have technology that allows us to quickly shape our world. We create new levels of abstractions over yesterday’s technology and leverage many existing machines in ways unimagined by their creators. Following a deep dive into two of the hottest contemporary technologies—blockchain and IoT—ideas emerge with the potential for significant social and economic impact. The kind of impact that would create a million jobs. But what kinds of practical blockchain IoT use cases are there that could achieve this within the transportation industry?

The Ethereum smart contract blockchain, Internet of Things, and motorization converge in the new utility coin "Motoro."

Sometimes, in such cases, the solutions are surprisingly simple.

At VIKING GARAGE, we help motorcycle owners to make money by renting out their bikes. In other words, we’ve built a motorcycle sharing economy, disrupting the personal transportation industry. And now we’re introducing the utility coin Motoro. But let’s take a step back so you can see why we need it.

Leveraging Existing Machines for Better Living

One important facet of the general worldwide transportation industry is that new machines and vehicles are generally expensive. In contrast, access to existing hardware is much less expensive and often the quality is similar. Some businesses operate just by renting out machines, which themselves are often actually leased out by financial institutions. (That situation is quite different from the current state of software.)

In particular, vehicles used at construction sites, on agricultural farms, in transportation, and even in the retail sphere are too expensive to buy for one-off projects. This includes personal transportation, and that is the reason we have ridesharing services like Taxify.

Uber Black, the luxury offering, is also a great experience in the world’s biggest cities—and for a small price. That is the whole point of sharing: Access to high-quality goods becomes easy and economical. We only really need Tesla vehicles when we’re actually moving from place to place: Ownership can be considered an artifact of usability. Who wants to worry about the battery degrading over the years, or worse, grand theft auto? I would choose the Polestar 1—when it comes out in April, it will not even be possible to buy it “for keeps.”

Ownership can be considered an artifact of usability.

The trend away from ownership towards a more utilitarian approach is a great opportunity for all machine owners. As I write this, I think of the excellent mechanics, riders, and motorcycle owners I met in Indonesia during our three-month-long stay. Often, their motorcycles were the main (and sometimes the only) wealth they possessed.

In that country alone, 7 million new motorcycles are sold every year. Nevertheless, it was close to impossible to rent specific bikes—in this case, dirt bikes—for the middle term, until I turned to private owners. When dealing with private owners, access to that type of motorcycle improved greatly, and the prices went down to a fraction of what bigger businesses asked for. The person owned a machine, they did not need it just then, and I wanted to pay to use it. It worked out.

That was simple enough. Why not scale it?

Here Comes Trouble!

In reality, making a scalable business that delivers quality services is not simple. Even if that first transaction went well, it was mostly luck. I would consider myself a realist: I trust that, if something can go wrong, then over the course of a hundred thousand transactions, it probably will—multiple times.

Machines are dangerous. Motorcycle accidents can be especially deadly. When accidents happen, then by law, and for the sake of insurance, a cause will be found—but where does that leave the owner and the rider?

As engineers, we understand the prevalence of human error. At VIKING GARAGE, we want to empower people to ride and owners to make money by renting out machines. We acknowledge the possible liability and intend to minimize the risk. We want the transaction to remain between the owner and the renter because we want to provide an open, transparent, and safe means for people to rent vehicles and ride.

So, what can possibly go wrong? Initially, it may be quite difficult to even access motorcycles for rent. Assuming we get past that, and there is a machine available, then the question asked by the owners is, “What if somebody steals it?” That’s a big problem! In contrast, the riders ask, “What if I damage the bike?” That one could potentially be solved with insurance and a formal rental agreement. Another question often asked by riders is, “Whose fault would it be, if I get in an accident?” Obviously, there are traffic regulations, but we need to take into account the mechanical state of the machine because machines can fail. Add to that the matter of formal trust between the owner and the renter, and between each of them and the local authorities.

Listed above are five significant problems: Access logistics, theft, responsible use and liability, machine state, and trust. We only seem to have three traditional solutions: Rental agreements, insurance, and traffic regulations. Those solutions have failed on numerous occasions. Do we need to consider all that, just to rent a machine? In the case of VIKING GARAGE, where we want people to rent machines to each other on a global scale, and stay safe, the answer is: Yes! Let’s consider how new technology can help us.

Who Does Blockchain IoT?

The good news is, we now have the technology to solve the aforementioned problems and/or improve on the existing solutions. Let’s list the problems once again, for clarity:

  1. Access to machines
  2. Theft
  3. Responsible use and liability for damage
  4. Machine state and service quality
  5. Formal trust

An initial solution, and one that we will build upon, was to represent the machines and rental transactions on a decentralized, public network. Some distributed ledgers, or blockchains, seemed like a natural fit. In particular, our attention was caught by the growing popularity and near-Turing-completeness of the Ethereum blockchain.

To allow the processing of transactions, two types of smart contracts would be sufficient: (a) one to represent the owners and the riders/renters and (b) another one to represent the machines. There is another requirement: A protocol to minimize the possibilities of fraud and misunderstandings, without any third party involvement. It’s likely that a set of physical proofs of rental will need to be documented with most agreements. Developing that algorithm can be tricky, but essentially, with just a handful of smart contracts, a blockchain can be used as the base platform for sharing economies. It is so convenient because the native function of blockchains is to facilitate distributed consensus and secure transactions.

Here is an early sketch of a machine representation as an Ethereum smart contract, written in Solidity. The contract already holds an interface for simple rentals, including an escrow system. The code compiles correctly and serves to outline how simple and effective the solutions can be.

pragma solidity ​^​0.4​.​18​; 
 
import​'../node_modules/zeppelin-solidity/contracts/token/ERC20Basic.sol'​; 
import​'../node_modules/zeppelin-solidity/contracts/token/SafeERC20.sol'​; 
 
/** 
* @title Ownable 
* @dev The Ownable contract has an owner address, and provides basic authorization control 
* functions; this simplifies the implementation of "user permissions." 
*/ 
contract ​MachineRepresentation​{ 
  using​SafeERC20​for​ ERC20Basic​; 
 
address ​public​ owner​; 
address ​public​ pendingRenter​; 
address ​public​ renter​; 
  string​public​ model​; 
  string​public​ make​; 
  string​public​ vin​; 
uint256 ​public​ rentalPrice​; 
uint256 ​public​ rentalCount​; 
// ERC20 basic token contract being held 
ERC20Basic ​public​ token​; 
 
  event​MachineRental​(​address indexed _machine​,​ address indexed _owner​,​ address indexed _renter​,​ uint256 startTime​, uint256 endTime​,​ uint256 _rentalPrice​); 
  event​RentalClaimed​(​address indexed _machine​,​ address indexed _renter​,​ uint256 claimedTime​); 
  event​MachineReturned​(​address indexed _machine​,​ address indexed _renter​,​ uint256 returnTime​); 
  event​ReturnConfirmed​(​address indexed _machine​,​ address indexed _owner​,​ uint256 claimedTime​); 
 
  /** 
* @dev The MachineRepresentation constructor sets the original `owner` of the contract to the sender 
* account. It also sets the model, make, and VIN of the machine. 
*/ 
  function​MachineRepresentation​(​string​ _model​,​string​ _make​,​string​ _vin​)​public​{ 
owner ​=​ msg​.​sender​; 
model ​=​ _model​; 
make ​=​ _make​; 
vin ​=​ _vin​; 
rentalCount ​=​0​; 
  } 
 
  /** 
* @dev Throws if called by any account other than the owner. 
*/ 
modifier onlyOwner​()​{ 
require​(​msg​.​sender ​==​ owner​); 
_​; 
  } 
 
  /** 
* @dev Throws if called by any account other than the renter. 
*/ 
modifier onlyRenter​()​{ 
require​(​msg​.​sender ​==​ renter​); 
_​; 
  } 
 
  /** 
* @dev Throws if called by any account other than the pending renter (temporary role). 
*/ 
modifier onlyPendingRenter​()​{ 
require​(​msg​.​sender ​==​ pendingRenter​); 
_​; 
  } 
 
  /** 
* @dev Allows the owner to rent out the machine to the renter, and specify the start and end time 
* and also the price for the rental 
*/ 
  function​ rentMachine​(​address _pendingRenter​,​ uint256 startTime​,​ uint256 endTime​,​ uint256 price​)​public​ onlyOwner ​{ 
require​(​_pendingRenter ​!=​ address​(​0​)); 
rentalPrice ​=​ price​; 
MachineRental​(​this​,​ owner​,​ _pendingRenter​,​ startTime​,​ endTime​,​ price​); 
pendingRenter ​=​ _pendingRenter​; 
  } 
 
  /** 
* @dev Allows the pendingRenter address to finalize the transfer and provide a token contract, with the cash to hold 
*/ 
  function​ claimRental​(​ERC20Basic _token​)​ onlyPendingRenter ​public​{ 
require​(​rentalPrice ​<=​ _token​.​balanceOf​(​this​)); 
token ​=​ _token​; 
renter ​=​ pendingRenter​; 
pendingRenter ​=​ address​(​0​); 
RentalClaimed​(​this​,​ renter​,​ now​); 
  } 
 
  /** 
* @dev Allows the renter address to return the machine, and transfer the cash from the held contract, to the machine 
owner 
*/ 
  function​ returnMachine​()​ onlyRenter ​public​{ 
uint256 amount ​=​ token​.​balanceOf​(​this​); 
require​(​rentalPrice ​<=​ amount​); 
token​.​safeTransfer​(​owner​,​ amount​); 
MachineReturned​(​this​,​ renter​,​ now​); 
  } 
 
  /** 
* @dev Allows the owner address to confirm the return of the machine 
*/ 
  function​ confirmReturn​()​ onlyOwner ​public​{ 
renter ​=​ address​(​0​); 
rentalPrice ​=​0​; 
rentalCount​++; 
ReturnConfirmed​(​this​,​ owner​,​ now​); 
  } 
}

I should point out that it takes more than a few finite smart contracts to cover all the many possible rental transaction types. We see the need for a modular library with reusable, minimal smart contracts, built with flexibility in mind and focused on vehicle rentals. That would allow other engineers to build final contracts for their use cases. Relay businesses, providing ĐApp interfaces to the contracts, would likely be able to grow simply by being gateways to specific smart contract types.

So what value does the Ethereum blockchain add, exactly?

First of all, the rental contracts would be transparent. All information on the public blockchain is, well, public. It is possible to refer to data that is kept secret and secure in another place, but the reference would remain public. Essentially, every rental agreement, along with the details that the two sides agree on, would be publicly available.

Secondly, that information would be safe, because a copy of it would be distributed over the whole decentralized ledger (blockchain). The trace would remain present forever, or at least till a hard fork would explicitly amend the blocks used to facilitate the transactions—but the chances of that are close to zero.

Thirdly, the information would also be secure, because every transaction on the Ethereum blockchain must be verified, i.e., consensus must be achieved.

The fourth reason to use blockchain is that the contracts are self-executing. Once signed, no further user action is required to assess if the conditions listed in the contract were met; that is, unless the parties agree to add such requirements. Do note, however, that the contracts cannot access information from the outside world directly. The reason for that is, Ethereum requires all of its state changes to be validatable by anyone, anytime.

Trusted authorities are thus needed to validate the incoming information from outside the blockchain and feed it with data. That role was filled by services called oracles, the most popular of them being Oraclize. Some decentralization can be achieved by referring to groups of oracles, like Oraclize does. But the current state of technology leaves one wanting better solutions. For example, what if the rental machines themselves could replace oracles?

The fifth reason: Smart contracts are self-enforcing. That means that, after being signed, and when set conditions are met, smart contracts are capable of taking action to resolve the agreement. Everything in the contracts is clear and automated, from signing the document to finalizing the agreement. The set conditions and consequences are unchangeable. Such contracts are safe for both parties and come with no surprises.

When comparing those five points (natively supported by rapidly evolving, extensively used blockchain technology) to the alternative (having to build support for safe and secure transactions and contracts, from scratch) the initial question changes. Why would we not want to use blockchain tech?

In fact, there are a few reasons not to. All blockchain transactions require gas to execute, meaning that they have to be paid for. The current average cost of a standard transfer on the Ethereum blockchain is 1 USD. The second reason is that the blockchain is quite slow. The third reason is that all the information is public. It would be simply dangerous, and often illegal, to keep vulnerable, personal data in a datastore accessible by everyone, without the possibility to ever change or delete those records.

I must note that transaction costs and speed differ greatly among blockchains. The Ethereum blockchain is extremely popular right now, but with the rise of relay chains like the Polkadot project, soon more suitable platforms will emerge. Decentralization is the most important feature, and it’s a given with any distributed ledger technology.

As for privacy, ultimately the data stored on the blockchain with formal agreements should be minimal. Users would be referenced by the addresses of their wallets, which are somewhat anonymous, or pseudonymous.

Motoro: Building a Cyber-physical Community

Let’s turn back to the five listed problems with sharing machines. We can now clearly describe how full-stack cyber-physical systems, consisting of blockchain-connected ĐApps, combined with off-chain SaaS and hardware and software IoT modules, can solve the aforementioned problems:

1. Access to Machines

The smart contracts used to represent machines would be stored on the public blockchain. Those representations would be independent of any central businesses and could figure in several ĐApps, reused according to will and availability.

2. Theft

Identification of the machines has the strongest effect when the binding is expressed on both the software side (blockchain) and the hardware side (embedded IoT systems). The cyber-physical network would consist of microcontrollers, connected to machines’ modules, like the onboard diagnostics (e.g., OBD-II) connectors, or the engine control units (ECUs). Those microcontrollers would provide the data to the smart contracts, used for identifying the machines. They would thus become hardware oracles.

Depending on the type of the electronic connection, Internet connectivity, and finally the clauses, which the parties agree on in the smart contract for the rental, the self-enforcing attribute of the contract could span over to the physical machines.

There are two types of interactions: Reading from the machine and writing to it. Simple examples of such interactions would be to turn on GPS tracking in the event that the machine was not returned, or even shut off the ignition or fuel injection, or change fuel mapping to the point where the machine is no longer operational.

Extreme caution is required when dealing with appliances which can write and change the machines’ state. The obvious hazards for human safety, pointing to the need for responsible applications, indicate the great power beneath such IoT systems.

3. Liability and the Responsible Use of Machines

The improvements in this aspect are a straightforward effect of the transparency, self-execution, and self-enforcement of smart contracts, meant to be used as rental agreements. Such documents can include all the clauses that the parties decide on.

Other types of documents, such as photos or videos, indicating the pre- and post-rental state of the machine, can be stored on the blockchain as evidence in the case of conflicts.

The smart contracts could also bind secured deposit contracts, like in the example above. Every step of the transaction and its resolution, along with all the assets, will at all times be transparent and predictable.

4. Machine State and Service Quality

Machines can look really good in photos, and even operate seemingly well when started, but many faults can remain hidden at first. Problems like worn bearings, overheating, and many others may require specific knowledge to notice, perhaps common to mechanics but not the general population.

Those faults will most likely present themselves, however, and ruin the experience of the renter, perhaps causing further problems. Imagine gasoline leaks on a hot engine—that was twice the personal experience of yours truly on two different motorcycles!

This problem can be tackled by the community. Rewarding users for describing their experience in comments, and delivering a scoring system, would instantly improve the situation. Distinguishing the comments and scores applied to the machines from those given to machine owners will further help to assess the mechanical state and service and communication quality. Also, that information could span across sharing economies.

5. Formal Trust

This last problem is solved together with the previous two. The nature of smart contracts makes for the transparency of the agreement, while the community will quickly assess if a user is acting maliciously.

Individual ĐApps could perhaps add an option to print out a version of the contract, applied onto a rental agreement schema, typical to the region and local authorities, and the generic solution emerges!

Flow chart showing the moving pieces of VIKING GARAGE's blockchain- and IoT-based Motoro system.

The solutions outlined in this section allow us, in our opinion, to greatly improve on the current situation with personal transportation rentals. The options for failure are minimized, and further solutions can be built on top of that basic set. The difficult, risky process of renting machines becomes less difficult and more easy to manage by introducing a cyber-physical system and community.

Motoro, the Missing Piece (Obviously!)

It is important to emphasize that Motoro can be used with other vehicle types, like construction and agricultural machines.

Motoro is an ERC20 token, which means that it obeys standards, can be used on the Ethereum public blockchain, and can be exchanged for Ethereum and other ERC20 tokens. It is disruptive because:

  1. It’s a global currency for motorcycle rentals.
  2. It has built-in documents, such as motorcycle rental, retail, or service agreements, deployable to the public Ethereum blockchain.
  3. It’s open source, with an initial dedicated service—the existing decentralized motorcycle rental startup VIKING GARAGE—and an open API.
  4. It allows for direct exchange of motorcycle rentals, services, and products, as well as most currencies.
  5. It provides quick access to personal transportation worldwide, utilizing the existing infrastructure and global availability of motorcycles, also for those with a regular car driver’s license.
  6. It rewards the activity of community members by dispensing new coins for posting comments and scores.

We talk about motorcycles all the time because those are the machines that we deal with at VIKING GARAGE. They are also very usable and not too expensive compared to other machine types. Plus, they make that cool sound and go really fast with a twist of the throttle. It is, however, important to emphasize that Motoro can be used with other vehicle types, like construction and agricultural machines.

The Road Ahead

We anticipate the following, initial global impact of Motoro:

  • New jobs: Hundreds of thousands of motorcycle owners, making new profits from existing motorcycles. (We’re already observing this at VIKING GARAGE.)
  • Market changes: A worldwide rise in private motorcycle rentals and general use of motorcycles, and a drop in motorcycle sales.
  • Quality of life improvement for motorcycle owners and riders: The biggest effect will be visible in Southeast Asia, due to the leveling of worldwide prices due to the common denominator, Motoro.
  • Scaling to other areas: Motoro being used in other machine sharing economies and being integrated with IoT technology.
  • Profitable asset for investment: Motoro is a standard utility coin, designed for direct vehicle rentals. It can also be used for the paying for rentals through VIKING GARAGE, and other vehicle sharing economies to come, everywhere in the world. The more people rely on the decentralized vehicle rental currency, the more worth the coin will have.

If you are interested in participating in this global movement, encompassing IoT and blockchain, there are many ways to do so right away. You can support the project, drive the development of Motoro, and get awesome motorcycle and IoT perks from VIKING GARAGE’s Indiegogo campaign. Another way would be to contribute to our open source projects at GitHub. Yet another way is to start using VIKING GARAGE, as a rider or machine owner. Finally, you are most welcome to join us at one of our Toptal Community events—blockchain IoT workshops—at Campus Warsaw (the Google Space) in Poland, where we discuss and plan Motoro’s further evolution. For that, simply search for Toptal on their events page. People of all skill levels are welcome as we learn together and create open-source blockchain-powered IoT solutions!

References:

Understanding the Basics

What is Ethereum?

Ethereum is a public blockchain and virtual machine. It is a network of people for making direct transactions. Ethereum's decentralized algorithms facilitate consensus, and all transactions get stored in immutable blocks.

About the author

Michal Mikolajczyk, Poland
member since June 29, 2014
Michal is a senior software engineer, and community leader for Toptal Warsaw. He communicates well and takes the initiative needed to help startups scale. Michal writes clean, functional code, automates infrastructure, and enjoys coordinating and scoping tasks. As a digital nomad, he travels the world with his family, speaks at conferences, and writes articles for the Toptal Blog. His professional interests include blockchains and data science. [click to continue...]
Hiring? Meet the Top 10 Freelance Ethereum Developers for Hire in June 2018

Comments

comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Michal Mikolajczyk
Blockchain Developer
Michal is a senior software engineer, and community leader for Toptal Warsaw. He communicates well and takes the initiative needed to help startups scale. Michal writes clean, functional code, automates infrastructure, and enjoys coordinating and scoping tasks. As a digital nomad, he travels the world with his family, speaks at conferences, and writes articles for the Toptal Blog. His professional interests include blockchains and data science.