I first had what I can only describe as a spiritual awakening about 10 years ago to the fact that technology would (figuratively) rule the world. And since then, I've been obsessed with wanting to understand how software works and how to build it.

Since that moment, my life has changed significantly for the better. I can only attribute it to the simple fact that I have relied not only on my own instincts, but on those of people much smarter and more experienced than I am.

My hypothesis is this: try to find and follow the lead of those who have exhibited a long track record of success, find interests in their wake, and do my best to excel at them (while continuing to explore my own curiosities).

This approach has led me to try and master JavaScript, and then React, and finally to build a successful consultancy. All this ultimately landed me on a team at AWS in a life changing experience that lasted a little over 3 years. All of this with no high school diploma or college degree.

During this time (like many developers) I've relentlessly dived into books, podcasts, blog posts, YouTube videos, and source code of every kind. But there has always been a topic that has captured my curiosity the most – futurism.

Futurists like Gerd Leonhard and Michio Kaku speak of a future that's sometimes beautiful and sometimes bleak. But it's always with the passion and phrasing that make your thoughts wander and move past the current moment in time and into a mind boggling world that does not yet exist.

I recently had another "aha" moment, similar to my technological awakening, that has completely changed the direction of my career and my life. In the spirit of these futurists, I want to talk about why Web3 excites me just as much as their ideas, but is instead happening as we speak.

Why is Web3 So Exciting?

This post is meant to dive more into what I think are the benefits and repercussions of Web3. If you want to know my interpretation of what Web3 is, see my thoughts here.

Web3 represents a handful of ideas which together bring about entirely new mental models, organizational structures, and community incentives. These force us to rethink many things that we have become accustomed to.

All of the recent innovation happening is possible because of decentralized protocols. The internet itself has thrived because of native internet protocols that we use everyday, like HTTP, FTP, TCP, and SSH.

One of the reasons these protocols have been so successful was that they were widely adopted and not subject to change. If I build a site using HTTP, people can use it without any centralized intermediary – we can trust that it is going to work.

There are two major pieces of native functionality that have been left out up until recently – payments and state.

Blockchains have enabled both of these things, opening the door for programmable money and state without the need of a centralized server, bank, or any intermediary at all.

Web3 Enables Ownership

One of the driving forces and the one that resonates with most people (and me) is that Web3 enables ownership.

Gaming

At some point the internet and gaming became almost indistinguishable. Not only because most games continue to receive updates over time, but the most popular ones are often the most interactive ones.

Fortnite took a lot of people by surprise because it created an innovative new combination of gameplay, peer-to-peer connection, and a unique business model – and everyone gets the game for free.

The experience is very interactive, you can join old friends and make new ones, there are constant improvements and enhancements that just happen automatically – the game is consistently evolving.

The monetization strategy was also innovative. Fortnite allows players to buy in-game currency as well as skins that they can wear in the game. If you have a child you know that the $65 you may have spent on the game itself is probably peanuts compared to the amount of money kids spend over the lifetime of their gameplay.

The problem, though, is this: when the player decides to stop playing the game or outgrows it, where has all that money gone? More importantly, who is allowed as a creator to benefit from all of the purchasing power? The answer is, well, Fortnite (the platform).

What if, instead, players retained ownership of their items and were able to keep or sell them? Their items would maintain, increase, or decrease in value like any physical asset.

These types of experiences and communities are now being made possible via NFTs. NFTs enable scarcity in a world where there was in the past no scarcity.

Axie Infinity is an example of how this looks in practice. It is a blockchain-based game that is the most successful of its kind, and has recently had explosive growth, catapulting it to over $1 billion in sales with over $780 million in the 30 days ending August 10 2021.

Parallel is an online card game that has done over $100 million in sales and is still extremely early. Dark Forest enables players to get paid to play the game.

When players realize they can retain much of the value of their time and investments while still enjoying the benefit of the game, it changes the way they view gaming and where they spend their money. But it also aligns new incentives around the game itself. If the game succeeds, they can share in that success, therefore they become even more invested.

The combination of ownership, community, and creators who have built audiences creates a whirlwind of new and exciting opportunities that we are just starting to begin see explored.

Ryan Watt, the head of YouTube gaming agrees.

Social media and art

Social media platforms were revolutionary. They allowed anyone from almost any background the ability to grow and foster large audiences using tools that were made free to anyone with a device and an internet connection.

There are no gatekeepers to becoming famous on social media as there have been in the past in film and TV. The intermediary was abstracted away and peer to peer connections and content sharing was made possible.

The flaw in these implementations is that they offer a terrible monetization system, not just for the platform but for the creator as well.

Advertising and the exploitation of user data is the go to play. Also almost all of the money generated by the platform, goes to the platform – the platform monetizes the content being created by its users in exchange for use of the platform itself. This is how social media works today.

In Web3, both creators and the community are able to gain and retain ownership within a platform, creating a synergy that, once experienced, makes the legacy interactions of the past seem archaic and undesirable.

When I say ownership, I don't only mean ownership of content, but actual equity as well.

We are seeing the beginnings of this in the art world of Web3. Artists who were, in the past, often barely making it are now able to leverage their platforms, often in collaboration with other community members or causes. They can create projects that leverage NFT collections to give community members as well as the public a way to participate and distribute equity all around. Art and code are also beginning to overlap.

Projects like Generative Masks allow talented creators like Takawo Shunsuke to leverage the skills he's acquired throughout his career to generate over $3 million in sales for his collection in just a few minutes. He's able to spread awareness for himself and his cause, and create another new community (of owners) simultaneously.

The best part is that he's giving it all back to the communities he's benefited from. On top of that, smart contracts allow him to programmatically enable a commission for any future sale that happens going forward, and in just a couple of weeks that amounts to another $600,000.00+.

Generative art itself is an emerging category that combines code and creativity and is something that could alone warrant an entire post. But it suits the coming era particularly well, as it enables artists to scale their creativity, community, and distribution.

There will continue to be a larger and larger percentage of digital artists because they can use powerful tools and programs to create art that can then be used in an infinite number of ways. They can then put it for sale on an international, 24 hour, liquid market.

OpenSea, the top online art marketplace today, has seen an absolute explosion in growth the past few months.

Even recently surpassing Etsy in sales.

Whether this type of volume continues, I have no idea. My guess is that there will be some volatility and fairly large swings both up and down. But there is definitely something there.

Most of these NFT projects are launched on Ethereum. Ethereum is soon merging a new consensus mechanism that will make NFTs orders of magnitude more environmentally friendly as a means of sales and transfer of art, which in the past all required ground transportation.

Future of social media

As it stands today, users of social media platforms can begin leveraging Web3 tools, communities, and platforms to begin monetizing their audience.

I believe there will be a breakthrough app that will disrupt social media as we know it built in the in the next 1 - 3 years that blends all of these ideas together in a way that we haven't experienced yet.

Many people have echoed a similar sentiment. Aave, a very successful DeFi protocol built on Ethereum, has already begun work on a decentralized version of Twitter:

Jack Dorsey of Twitter is also working on a Decentralized version of Twitter, though I believe that this type of application will ultimately come from the community or a DAO.

DAOs, grants, community ownership, and social tokens

DAO stands for Decentralized Autonomous Organization. You can read about what a DAO is here, here, and here, but I want to focus on how DAOs will play a part in the new creator economy.

Shared ownership is a characteristic you'll see carried across all areas of Web3, including how we think about companies and incentive structures around how business is done.

In Web2 companies, cash usually comes from investors and there is no value returned to them for years. Ownership is largely concentrated in the first handful of employees along with their investors.

It usually takes years to reach a point where investors or employees with equity can begin to see any return on their investment and time spent, often through the old ways of advertising and exploitation of user data.

Web3 and blockchains bring about entirely new business models, made possible by tokenization and cryptoeconomic protocols.

There are quite literally countless ways that these tokens are being utilized to create new ways of collaboration and building, ranging from DAOs to web infrastructure to micro-economies:

PartyDAO which created over $200,000 in revenue in its first day, was "built in 3 months by a small group of internet friends working part-time", and is backed by a smart contract

Compound, a decentralized finance protocol that allows you to lend and borrow cryptocurrency without trusting a third party with your funds has a market cap of over $2 billion as of this writing

Super Rare is a digital art platform that recently launched a token, airdropping as much as $140,000 to its earliest users

Gitcoin is a platform that enables developers to get paid for working on open source projects

Graph Protocol is a decentralized web infrastructure protocol that allows developers to build APIs to enable the performant querying of blockchain data, all enabled by its native utility token

Seed Club is a social token incubator that’s focused on helping creators launch and grow social tokens

Friends with Benefits is a social DAO and community that I'm part of that is 100% owned and governed by the participants

PleasrDAO allows investors to come together to purchase high-value non-fungible tokens like this piece from Edward Snowden.

Most DAOs have desirable grants programs, enabling developers and other participants to work with various teams and projects at their will, on things they find interesting or that fit their skill set.

There are more and more people beginning to work full time for grants and with DAOs vs traditional full time employment.

Conclusion

If this sounds like something you're interested in being involved in, I'd suggest that you jump right in. Try P2E (play to earn), get involved with a DAO, or even mint your own NFT.

Also check out How to Get into Crypto, Ethereum, and Web3 as a Developer which is what I put together after getting my own start in the space.

If you want to learn more about these ideas, I encourage you to follow some of the people I mention in this post:

Also, here are some of my favorite articles that touch on some of the stuff I've outlined here:

The Rise of Micro-Economies

The Creator Economy: Today Vs. 2025

The Value Chain of the Open Metaverse

The DAO of DAOs

Thanks to Aditi for helping me with ideas and edits as I was getting this across the finish line 🙏

Lately, I've been talking about my move into the Web3, Ethereum, and crypto space since making the switch from a traditional web, mobile, and cloud background.

Since making that move, a shocking number of people have reached out to me who are also thinking about doing the same.

It's really great to see so many other people interested in these fields. And if I'm being honest – it feels validating to know that so many others are also on the fence and are so deeply interested in the space as well.

As for me, I was nervous about making the career switch. Moving into a completely new area of specialization, with a technology I was still getting ramped up on, and a community I was not yet involved with, was a big leap. Especially compared to a very comfortable role with a FAANG company that paid really well (and a team that I really loved).

After over a month, I have zero regrets with the change. I'm also the happiest I've been in a long time, and am excited and energized about the things I have the opportunity to work on everyday.

I decided to write this post to give a blueprint for anyone looking to get into blockchain, crypto, Ethereum, and Web3 from a traditional development background. I can point people to this blog post the next time I get asked how to get into the space.

I'll break this article up into a few main parts:

1. Technologies and resources to learn
2. Tradeoffs and considerations
3. People to follow
4. Companies hiring and doing interesting stuff
5. General tips and landing a job

Let's dive in.

Technologies and Resources to Learn About Ethereum and Blockchain

What I'm most interested in is usually a function of where I predict technology will be in the near future and where I see the current momentum being. So that's what I will focus on here (and this is what I am doing personally).

To me, the most exciting parts of this space are decentralization, DeFi, governance / DAOs, and decentralized web infrastructure.

Because of this, I'm focusing on both Ethereum development and Solidity. With the Solidity programming language ,you can program smart contracts for Ethereum as well as for many other EVM compatible blockchains.

As of this writing, Ethereum also has the powerful and important combination of momentum, developer mindshare, and existing production dapps.

Ethereum is also currently moving to a new consensus mechanism, proof of stake. This addresses the environmental concerns I used to have about how cryptocurrency works at a core level.

Once you learn how everything works fundamentally, I encourage you to then check out other blockchains and projects outside of Ethereum and EVM.

This will give you a better understanding of the industry as a whole. It will also help you see if there are other projects that attract you or that you believe are better approaches to achieving the goal that is Web3.

Consider looking into Solana, Polkadot, Near, Avalanche or Cosmos.

To get started learning blockchain development with Ethereum and Solidity, I suggest you do the following:

1. Read the Ethereum docs

Scan through the Ethereum docs. Be sure to check out the section Intro to Ethereum as well as anything else that catches your eye.

Also be sure to check out the dapp showcase to get a good understanding of the successful apps being built and used in the current ecosystem.

2. Read the Solidity documentation

The Solidity docs are a really good place to get started, especially solidity by example. This gives you a few examples of popular smart contracts like voting, an auction, remote purchase, and micropayments.

You can copy and paste these contracts in the Remix IDE to start executing and modifying them to see how they work.

I also did a video walkthrough of the voting contract here.

3. Get comfortable with the Remix IDE

It's really easy to play around with and start building smart contracts without having to set up any type of development environment by using the Remix IDE. It's part of the Remix Project which is funded by the Ethereum Foundation.

This Remix IDE allows you to create, edit, and execute smart contracts directly from your browser. It offers a perfect environment for learning how solidity works. It's also great for building out various types of smart contracts and playing around with them as you are learning both solidity and how to interact with Ethereum

4. Try building out a full stack dapp

In addition to Solidity, the other parts of the the development stack include a local Ethereum environment like Hardhat or Truffle, a wallet like Metamask, as well as a client-side library that allows you to interact with the blockchain, like either Ethers.js or Web3.js.

To understand how all of this all fits together, it's useful to build out a full stack dapp on this stack from scratch. You can set up the front end project as well as the local development environment and deploy, run, and interact with a smart contract on the blockchain.

Here are two introductory courses to get you going with this:

1. Ethereum Programming Tutorial - DeFi, Solidity, Truffle, Web3.js
2. The Complete Guide to Full Stack Ethereum Development (and here it is in article form, too)

5. Consider reading these books

The space itself moves very quickly, so technical books often get out of date just as quickly. The fundamentals of what Web3 is, though, have not changed much at all.

There are a few really great books that helped me not only grasp the current state of everything, but that also helped open my eyes to the future possibilities and opportunities that lie within it.

Token Economy - How the Web3 reinvents the internet

If you only read one of these books, this is the one I'd say is the most important. It is a masterful deep dive into all of the shortcomings of the web as we know it, what Web3 aims to be, how it will affect various parts of our lives as we know it, and what needs to happen for this vision to be realized.

You can view the book here.

The Infinite Machine - How an Army of Crypto-hackers Is Building the Next Internet with Ethereum

This is the amazing story of how Ethereum came to be, walking you through the history of it all. It is a very thorough and entertaining account of the origin story of Ethereum, I highly recommend checking it out.

You can view the book here.

New Village - Power Back to People

This is a really cool story of how blockchain technologies and decentralization will affect the future of the world.

You can view the book here

How to DeFi

As you can probably tell by the title, this book focuses on how you can start using DeFi today. It gives you a good understanding about how you can use it today as well as some applications of it that we will see at some time in the future.

You can view the book here

The Spatial Web

The Spatial Web is a book that explores the future of the web and all of the implications, not only of Web3 and decentralization, but how everything will come together to enable things that we may have not yet considered.

It does a good job weighing the positive and negatives as well as ways that we may be able to address any negative outcomes of what is to come.

You can view the book here

And here are a couple of solidity books:

• Hands-On Smart Contract Development with Solidity and Ethereum
• Mastering Ethereum

6. Listen to these podcasts

Here are some good podcasts:

• Founders of Web 3 – The people that are creating and building the next phase of the internet.
• Bankless – The Ultimate Guide to Crypto Finance
• Into the Ether – Podcast about Ethereum
• Crypto 101
• Epicenter – Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies

7. Watch these YouTube channels

• Ethereum Foundation
• Eat the Blocks – Short videos on blockchain development
• Finematics – Sharing interesting DeFi videos
• Dapp University – Videos in the Ethereum space
• BlockGeeks – General Blockchain Training
• The Daily Gwei
• Austin Griffith

I've also begun doing videos and tutorials on Ethereum and Solidity, so consider checking out my YouTube channel.

Tradeoffs and Considerations of Switching Careers

There are always things to consider when making a career transition, but especially when considering this space.

There are a lot of positives, but there are also unknowns as well as negatives. Let's talk about some of them.

It's nascent tech

While there are many existing dapps and companies already flourishing, this space is very much still coming into existence in many ways.

There are a lot of problems that we still need to solve, and there are no clear answers for many questions you'll have. The problems being solved are often complex, sometimes combining one or more aspects of distributed systems, game theory, cryptography, economics, social and political science, identity, psychology, and more.

Because of this, there are still things that we cannot yet build with the existing solutions that are available.

I personally think this is one of the more exciting things about all of it it, but it's not for everyone.

It's a volatile space

Many of the projects are built around various types of tokens. The value of many of these tokens rises and falls dramatically, and you often see that people gain and lose excitement in the entire space based on these swings.

If you haven't fundamentally bought into the ideas behind decentralization itself, you may find these ups and downs mentally taxing.

It's full of speculation

Because a lot of people only buy into certain tokens in a speculative way, it attracts some people who are in it only for the money.

You see things like scammers trying to get over on people and steal their money, endless talk about price swings from people who are speculating, and outright scam projects that often discredit the industry as a whole.

This is an annoying part of it and I don't really see it going away anytime soon.

This thread

I would also check out this Twitter thread. Although I have not experienced all of these things, he is definitely shining a light on some of the things I have seen.

General Tips and How to Land a Blockchain or Crypto-Related Job

There are many areas within the space that you can focus on and provide a positive impact on a team. I'd look into the different areas like governance, DeFi, NFTs, and decentralized web protocols to see what interests you the most and then focus on that.

There are a lot of opportunities and a lot of ways to stand out and get noticed. If you find an interesting project and would like to get involved, jump right into their community and ecosystem and start learning. Then see where you may be able to help out. Join their Discord or look at their GitHub issues to find ways that you can contribute.

This will give you an opportunity to meet people involved in the project and will open up discussions for potentially landing a role with them. In fact, it is very common for people within the teams to take notice of active community participants, they will then often reach out and try to recruit you without you even applying.

The pay is usually good. Depending on where you are coming from, it could be more or less, but it's probably not going to be at the high levels of what you see at FAANG companies.

There is probably more potential upside. Most companies offer a combination of base pay + equity in the form of their digital token, so if you stick around and can help make the project successful and the value of the token goes up, you can often make more than what you would in many other areas.

People to follow on Twitter

Here are a few people who you may consider following on Twitter:

Vitalik
Ashleigh Schapp
Arthur Hayes
Stani Kulechov
Gloria Kimbwala
Niran Babalola
Ric Burton
Dennison Bertram
Mana Silvora
Austin Griffith
Santiago Palladino
Zaki Manian
Anthony Sassano

I also found this comprehensive list created by someone on Twitter.

A few people on my team at Edge & Node:
Yaniv Tal
Tegan Kline
Eva Beylin
Adam Fuller
Brandon Ramirez

Teams doing interesting stuff (and hiring)

Compound
Uniswap
Chainlink
Skynet Labs
Aave
Matic
Livepeer
Consensys
ENS
OpenZeppelin
Foundation
Zora
Synthetix
Digital Currency Group

You can also find a pretty decent list of job opportunities in cryptocurrency here.

Also, my team at Edge & Node is hiring!

Conclusion

Did I mention this space is volatile? Be ready for some high highs and low lows, but also for some of the most fun you may have in your career.

You'll be working alongside some of the smartest people in tech trying to solve some of the most complex problems that I think will ultimately have a massive positive impact on humanity.

TL;DR Check this back end and front end solutions for delegated transactions. It is universal for any token which supports the delegation of its functions. Read more below.

This mostly technical article provides a universal framework and a working solution for Ethereum tokens and applications that eliminates the need to pay fees in Ether, a problem that is practically killing the user experience of many blockchain applications.

Imagine spending dollars and then being asked to also hand over some Hryvnias as a transaction fee. That's how Ethereum tokens work so far.

In other words, for example, to transfer any Ethereum token (like Tether, DAI, BAT, DREAM, etc.), the user has to also spend some Ether (internal Ethereum platform currency). This introduces a big inconvenience that prevents the mass adoption of DApps: users have to purchase multiple currencies instead of just one to interact with the blockchain network.

The Problem

Tokens, as we imagine them today are just fuel for applications and services on top of blockchain networks. Organizations create their own tokens (using ICOs, IEOs, etc) and run services/applications that utilize them, introducing their own micro-economy (widely known as a token economy). But almost every token turns out to be quite a complex currency itself. By design of how blockchain networks work, in order to do something with your tokens, you also need another currency — often Ether (for Ethereum) to be able to transfer tokens.

To illustrate the problem, let's look into how users come to use different blockchain-powered services and applications like:

• Trickle - where you create secure, hourly-based contracts with an untrusted party in any token
• Loom - where you use Loom tokens to create sidechains in Loom Network
• Cryptokitties.co - where you breed, trade and transfer kitties (ERC721 tokens)
• Others (there are a lot!)

All these applications use tokens, as well as they require you to purchase Ether. The complexity of using crypto tokens as we know them today is one of the biggest reasons why 99% of crypto startups fail (or avoid adopting real crypto, for example, by replacing it with virtual coins).

As you may already know, the harder it is to use the application, the fewer users it will get right from the beginning. This is something known as The User Onboarding Funnel, which is still a big pain for blockchain-powered applications and services:

The typical user onboarding funnel of a decentralized, blockchain-based application

To understand why I put 0.001% of users prior to the service use, let's see what exactly purchasing some Ether means:

• Creating a crypto wallet
• Registering on Exchange (and learning all the exchange rules, including country policies!)
• Passing KYC (though it's getting easier, still, many countries have limited access to exchanges)
• Purchasing a minimum allowed amount of Ether (usually, it's whopping $50 while you need just nearly $0.05 to perform one or two transactions)
• Withdrawing Ether to your wallet
• Not to mention reading lengthy guides on how to perform all these steps properly

Instead of just:

• Creating a crypto wallet

Of course, it highly depends on how the application or service is made. But, so far, there was no better simplification of the onboarding flow as just cutting crypto tokens from there, or making them fake, "virtual" currency with deposit and withdrawal function. Unfortunately, the latter approach is now the common one across all startups and companies adopting crypto, for many good reasons. Another reason could be a monetization strategy, but this is another big story worth a dedicated article (Interested? Comment out!).

Getting back to the transaction fees problem, we can state the following, which is hard to argue with.

It is natural for the user to purchase only the cryptocurrency they really need (for instance, tokens: Tether, DAI, BAT, DREAM, etc.), and they would normally expect to pay any transaction fees in this cryptocurrency.

So why not just allow them to do so? Because it's quite complex indeed. Let's see why, and how this has just got easier with our open-sourced solution (at least for Ethereum).

Existing Approaches

From the very beginning of blockchain existence, there were a couple of solutions that could simplify the user onboarding flow to the flow depicted below, avoiding the step of purchasing an intermediate currency like Ether. Still, creating a blockchain wallet is not an easy step, but some users who do understand the value of the application/service go through this step quite well.

The user onboarding funnel with delegated transactions

The solution which allows to avoid using intermediate currencies (Ether for Ethereum) is called "delegated transactions", or "meta transactions".

In short, delegated transaction, or "meta transaction" in blockchain is the type of transaction which performs an intended action on one account's behalf, while it is conducted (published) by another account (delegate), who actually pays fees for the transaction.

There are multiple approaches around the internet of the generalized concept of delegated transactions I am presenting in this article. But it seems that none of them are still widely adopted, as these approaches are quite complex by its nature, very specific as for the implementation, as well as some of them are quite complex to standardize. To be more constructive, existing approaches can be divided into 3-4 groups: those which use proxy smart contracts, those which embed delegation into a smart contract itself and, theoretically, there is an opportunity for the blockchain-native implementation (say, Ethereum 2.0).

1. Delegated transactions approaches which use proxy-contracts

Proxy contracts, or, in this context, identity contracts are tiny contracts deployed to replace the user account which wants to avoid paying fees. This smart contract is programmed to act as a wallet, as well as a "caller" (sender) of other smart contract's functions. The key is that it is a delegate account that triggers all the actions, while the true "owner" of this smart contract is another user. The user just generates correct signatures in order to control their funds stored on a smart contract address (= in their wallet).

A visualization of how identity contracts look like

Pros of this approach:

• It works with any tokens and contracts which are already deployed to the network

Cons of this approach:

• Users don't see tokens in their wallet, because they are physically on an identity smart contract
• As a result, a need to develop custom UIs and custom tools/wallets
• Identity smart contract deployment and assignment initial fees, as opposed to no fees at all
• Requires a comprehensive standard to be widely adopted

2. Semi-delegated transactions via "Operator" pattern (ERC777)

There is a token standard that describes this approach — ERC777. In short, any token holder can authorize any other account to freely manage their tokens. I won't call it delegated transactions but nevertheless, I need to mention that, as here we somewhat delegate control over your tokens to other accounts.

A visualization of ERC777 standard's "operator" pattern

Pros of this approach:

• Standardized

Cons of this approach:

• Highly centralized around the "operator" accounts
• Weak security due to operators have 100% control over your tokens
• Initial fees for approval transaction
• Requires additional UIs/tools development

3. Delegated transactions embedded directly into a (token) smart contract

Just the same as it is possible to implement custom fees in a proxy smart contract, paying fees in tokens can be implemented directly in a token smart contract. For example, using the approach I described in my previous article, it is possible to implement a function in a smart contract, which will transfer tokens accepting the user's signature, instead of requiring the user to call this function directly. We have implemented this approach in our DREAM Token, which is used on our dreamteam.gg platform.

A visualization of how embedding delegation into the token contract looks like

As you may notice, in contrast to the previous approach there is no identity contract anymore, and there is an optional way to call other smart contracts directly from the token contract.

Pros of this approach:

• Users see their tokens as usual on their wallet's balance
• No initial fees for account initialization
• May not even require a standard (continue reading)

Cons of this approach:

• If you have a (token) smart contract that is already deployed to the network, you cannot apply this approach to it directly. While you can always deploy a new token and, for example, a "migration" utility, which will allow other users to swap tokens (burn the old token and mint a new one)
• Because a standard for this approach is yet not well-defined, implementation can drastically vary
• A need to develop custom UI/tools for delegated transactions (continue reading — solved!)

4. Delegated transactions on the (blockchain) platform level

This is far the best one of all the described approaches above but also the one which is not implemented anywhere yet (by anywhere I mean the most popular blockchain platforms). There is a hope that its support comes with Ethereum 2.0 release, or at least I've heard from Vitalik that they are in progress with something cool there.

Theoretically, we can imagine this approach as being able to make an "offline" signature of two transactions at a time: one which does something useful for the signing account which wants to avoid paying fees (for example, transferring tokens) and another one which does something useful for the delegate (for example, paying fee in tokens to the account which executes these two transactions).

A visualization of how platform-native delegated transactions could look like

But the problem is, regarding Ethereum 2.0, this feature has a chance to land only in 2022 or even later. I also suppose that this feature will still require a dedicated back end (similar to the one which is introduced within this article), as it is hard to imagine how miners will accept fees in tokens. Simply put, if some of them refuse to accept fees in tokens than it makes little sense to do it on a "mining" level at all, not to mention how much would it take to track all token prices and volumes across exchanges, in a decentralized manner.

Pros of this approach:

• No need to change smart contracts that were already deployed
• No initial fees for account initialization
• May not even require a custom UI/tools if standardized

Cons of this approach:

• Most likely, will still require a centralized back end (the "delegate")
• Not yet implemented on a platform level (as of 2019)

The Solution

From the four approaches above, except for the platform-level approach which is yet to be implemented and standardized in 2022+, the most appealing one is the third approach, where we embed delegated functions directly to the token smart contract. Thus, we save the standard token paradigm allowing wallets to normally work with the smart contract and have no need to wait until delegated transactions will land natively in one of the top blockchain platforms. We will stick to this approach and make it universal just below.

Delegated transactions support programmed right in the token smart contract is awesome. But how to deal with its cons? In fact, the only problem which is tough to deal with (as you cannot modify existing smart contracts), you will need to deploy a new token smart contract if you have already deployed it without delegated functions (for instance, standard ERC20 or ERC721 tokens). The next step, in this case, would be adding a way to migrate tokens from one smart contract to another. For example, you can decide to implement one more function in the new smart contract that will allow token holders to migrate their assets from the old smart contract.

Token migration function implementation can vary, starting from implementing receiveApproval in the new token, if the previous token supports approveAndCall, or ending with utilizing approve + transferFrom framework if you have just a bare minimal ERC20 (the user _approve_s tokens to the new token contract address and then calls a function in the new contract which burns old tokens and mints new ones — but this requires a standard fee for the user for the approval transaction). Actually, there is more: you can decide not to burn old tokens but to "lock" them on a new token smart contract, minting new tokens — this opens an opportunity to implement two-sided token migration, which is awesome — you won't need to list the "new" token on the exchange, while the users will still be able to send the old token to exchanges without fees in Ether! If you are interested, please fill the issue here if you want to know more details on how to do it, because this approach is worth a whole new article.

In my previous article, I provided an example of the token smart contract which supports delegation of such functions like transfer, transferFrom, approve and approveAndCall. Exactly these "delegated" functions allow users to pay fees in tokens, instead of Ether.

How delegation works in Ethereum, in short. Read more in this article.

But that wasn't enough to start the mass adoption. In this article, I am providing a complete universal back end solution (Transaction Publisher in the picture above), as well as a configurable widget (check it here), which allows you to replace Ether fees for token fees today.

Some key points before we dive in:

• This delegated transactions back end is made to be universal, or standard-free, meaning that you can have any implementation of delegated functions and use any signature standard(s) in your token. From the back end standpoint, you just need to write a manifest file for your token, describing its usage.
• Currently, converting collected fees in tokens back to Ether is a manual action on exchanges. But it could be a potential improvement for automation in the future (if needed).

The Concept Behind the Universal Solution

What does it mean that the token supports delegated transactions? Let's look at it using the ERC20 standard token as an example.

Smart Contract

As for the token smart contract, the approach is quite straightforward. In addition to every method like transfer(to, value) which we want to be "delegatable", we add a companion function which, instead of inspecting msg.sender, accepts the signature of a user and does the same what the original function meant to do by validating this signature inside the smart contract. Thus, for example, for transfer(to, value) function we can add transferViaSignature(to, value, ...aditionalParams) function. As you know from public-key cryptography, no one can create a valid signature except private key owner, so that's why this approach is as secure as Ethereum itself.

And the coolest part is that the delegated function implementation, as well as its signature doesn't matter much, from the delegate back end standpoint. You can even decide to implement one "call by signature" function for all other functions that the smart contract supports. Delegate back end just need to know how to call this function, which is solved by providing an off-chain contract manifest for the delegate back end. For example, the argument additionalParams in transferViaSignature can vary and can include anything from this list, if not more: fee, fee recipient address, expiration timestamp, a signature standard used, a signature itself, nonce number or any other unique delegated transaction ID and so on. Regarding the smart contract design, in order to understand why exactly these arguments, read my previous article.

We also want to allow "delegates" to earn something in order to cover their Ether spending, as well as to be profitable. Thus, we have to add a fee, but a much more natural fee than Ether: a fee in the token itself. So that, for example, if you need to transfer 100 tokens, you pay 3 more tokens to the delegate depending on its price and network conditions to perform a transfer, and this should be preserved in a smart contract logic.

Back End

All right, now we have a token that allows transferring someone else's tokens by using their signature. Now, the crucial part is to automate the process of requesting and publishing such transactions. And here where our open-sourced back end (and a front end) kicks in.

Below is the sequence diagram describing how front end (client) communicates with the back end from the delegated transaction request to its publishing to the network:

1. (hidden on the diagram) The client requests information from the delegated back end to understand which contracts does it support, as well as which functions can it delegate.
2. The client requests a particular smart contract's function to be delegated. Most importantly, the back end returns the fees it charges and a data to be signed by the client.
3. The client signs the data in their wallet. Signing is a free operation, unlike publishing transaction to the network.
4. The client sends their signature back, thus confirming their intent to perform this particular delegated transaction. The back end validates this transaction against the current network.
5. Finally, the back end publishes a transaction to the network.
6. (hidden on the diagram) The client constantly polls the back end for the delegated request status until it receives a mined status. Note: it is important to poll the back end instead of using a transaction hash to understand when the transaction is mined. It is a very common case when the gas price suddenly increases, and, in order for the transaction to be mined quickly, the back end may republish it with a higher gas price. Though it is currently not implemented, it is very likely to be implemented soon.

Sequence diagram representing the simplified flow of how delegated transaction is delivered to the network

This approach is universal, and only requires the manifest file for the back end to understand how to calculate fees and which signature standard to use on the client side. Here is another visualization of the components of the system and their interaction sequence:

Component diagram

We've provided a comprehensive documentation for this solution. You can check how the back end API is structured, as well as find the token manifest file which describes how to work with a particular token contract. We encourage you to contribute your own tokens there!

And you don't need much setup: it's already there with the universal front end!

Front End

Open-sourced front end part of the delegated transactions is the user interface which is set up for every token: just run your delegated transactions back end and you are ready to go!

What it looks like

It is made to be an embeddable widget, which will guide the user through the procedure of sending tokens. You can plug any back end, token or call any token function with it by utilizing additional URL parameters you can specify.

Using this widget, and by implementing something similar to widely used, but not standardized approveAndCall function in your token smart contract, you will be able to call other smart contracts with arbitrary data by paying fees in tokens!

Here is a quick guide for you if you want to play with this UI yourself:

1. Access the widget via this link.
2. It will ask you to switch to the Kovan test network.
3. Get some test Ether using any available Kovan faucet.
4. Use test Ether to mint some test tokens: call mintTokens function in a token smart contract which will give you 10 test tokens.
5. Now, get back to the widget and try to transfer these tokens!

If you open up the browser's developer tools, you may notice that there are a couple of back ends connected by default — they provide the front end with all required information to make a delegated request according to given widget URL parameters. All backends are requested during the widget load and, if any of them can provide a delegation for a particular contract's function, then the widget requests additional information: fees, supported signatures, etc. If there are multiple back ends which can delegate the same contract function, all of them are requested and the back end which provides the best fee will be used for the transaction.

Transaction mining time is seemingly fixed, but it can vary because of the network conditions. The back end uses an actual network fee when calculating the token fee, however, it may change before the user decides to execute the transaction. Thus, the "underpriced" transaction is submitted to the network and can be pending for a while. While the back end is currently not programmed to deal with this case, it might be implemented in future — transactions will be republished with higher gas fees in case of the network fee increases. But, we will also need to count this into the token fee.

Signature Standards

The last question which you may be wondering is — which signature standard to use for your token. There are several available: _ethsign (deprecated), _ethpersonalSign (note that old Trezor and Ledger produce a different signatures because of ambiguity in a standard, so you may want to include both), _ethsignTypedData (deprecated), _eth_signTypedDatav3 and so on. I would recommend supporting at least two: ageless _ethpersonalSign and new _eth_signTypedDatav3 (as of 2019).

Signature standards comparison — what the user sees

The front end is programmed to always prefer the user-readable standard like eth_signTypedData_v3 to any others eth_personalSign. So if your token supports many signature standards, and you added all of them to the manifest file of your token, it will display eth_signTypedData_v3 prompt first.

Conclusion

Delegated transactions are great: they solve one of the biggest problems of blockchain application adoption, which eases the mass adoption of crypto overall. I will put a couple of thesis in a Q&A format here for you to answer the last questions that you may still have after reading this article:

• Our open-source solution is free to use and production-ready, feel free to apply it to your applications or tokens!
• The described approach does not compromise security nor centralization. Think this way: the centralized back end is only a helper for someone who wants to transfer tokens without fee in Ether. If the back end is hacked, or it is just unavailable, there's no problem to interact with the network just as it was before, by paying fees in Ether. As well as the back end cannot harm or trick the user to steal their tokens when a proper signature standard is used (it's up to your token implementation).
• There is a way to support delegated transactions for existing, already-deployed tokens. However, it requires the additional Ether-consuming step to migrate existing tokens to a new token contract. And, by programming a new token contract properly, as well as designing your application to work with both tokens you can even avoid a need to list a new token on exchanges.
• By using the existing tokens as an example, which is available in delegated transactions back end and front end repositories, you can produce your own manifest for your own token.
• Read the instructions on how to set up your own back end for a token, and then add it to the URL of your widget (or commit to the open-source repository).
• Have a token which already supports delegated transactions? Plug it into our UI with these three quite simple steps: (1) create a manifest for your token and put your token abi file while setting up the delegate back end, (2) run this back end, exposing a public API URL and (3) use URL parameters in a widget to reference your back end or commit it directly to our open-source repository. Read more about it in GitHub's readme file.

I hope that was a really helpful piece of information for all the searchers of incredible. Feel free to contact me or fill the issue here if I missed something. Have fun, let the token economy be simple!

For a long time, I was looking for a good Portfolio web app that can help me to easily track my Cryptocurrency profits/losses until I’ve decided to develop such on my own with the help of Firebase and Angular! Yes, it’s that easy, let me explain to you why.

Firebase gives the perfect tooling for applications with user authentication and Real-time database storage needs. It provides rich documentation with a variety of dev examples to help anyone gain a better understanding of how to create stellar apps.

I have covered the Angular application bootstrapping, using Ignite UI CLI, in another blog post.

This article aims to:

• Go through the Firebase installation and setup.
• Set up Firebase Authentication.
• Implement Real-time database storing and synchronization.
• Add Observable data services.
• Visualize the data in an Angular application.

Configure a Firebase account

I want to go through the steps that we’ve taken to set up the Portfolio Firebase account. Projects are created from the Firebase console by choosing Add a new project. Once the Create project form is submitted you will see the following Project Overview.

Firebase Project Overview

Under the Project Overview section, you can find all development tools that are used for Authentication and Data storing. Here is also located the configuration which is used in the Portfolio Web App. This configuration is generated by pressing Add Firebase to your web app, and it is later added in application’s app.module.ts file.

Let’s get back to the sidebar on the left and select Authentication. From here we have access to the Sign-in methods that we need in the app. Navigate to the Sign-in tab, there you can see the providers that are enabled and used in the Portfolio application — Google, Facebook and Email/Password provider.

Sign-in providers let users authenticate with Firebase using their Facebook and Google accounts by integrating their logins into the app. As for the Email/password provider, it represents a simple authentication mechanism by using only email and password. Firebase Auth provides built-in validation rules verifying the user entries, so we don’t need to configure something additional here.

The “trickiest” part here was the Facebook provider configuration because we needed to have a Facebook application in order to authenticate the login. We’ve created a FB app from Facebook Developers which provided us with the App ID and App Secret requested from Firebase.

Both API ID and Secret should be filled when enabling the Facebook provider. As for the Auth redirect URI (from the provider window) it should be pasted under Facebook/Facebook Login/Products section/Valid Auth Redirect URIs.

Let’s continue with the Firebase console. From the Database view page, we’ve created a Real-time Database.

Firebase Database View

In this view, we can find information about the application data items and write/read security rules. Below are the rules used by the Portfolio application:

{  "rules": {    "items": {      "$uid": {        ".read": "$uid === auth.uid",        ".write": "$uid === auth.uid"      }    }  }}

This Security Rule configuration will allow only authenticated users to be able to read and write in our database. If you want to learn how to define more advanced rules, I strongly recommend checking out the Official Security & Rules section.

Okay, where were we? Now that we’ve gone through the Portfolio Firebase account creation, let’s see how the Firebase development project was created.

If we didn’t have a project created already, I would have recommended starting with installing the firebase CLI, that provides a variety of tools for managing and deploying Firebase projects. BUT we’ve bootstrapped the Portfolio Angular Project with Ignite UI CLI, so we just needed to install AngularFire and Firebase from npm. We need both packages in order to communicate with Firebase. AngularFire is the official library for Firebase and Angular development.

npm install firebase @angular/fire --save

All AngularFire modules that are used in the application are added in the app.module.ts file:

• FirestoreModule is needed for the database features like working with collections, queries, and services for data streaming and manipulation.
• FireAuthModule is needed for authentication features like monitoring authentication state, Log-in providers and security.
• FireDatabaseModule allows us to work with Realtime databases. It’s very efficient for mobile and web apps that require synced states across clients in Realtime.

The only common module that is not used in the Portfolio app is AngularFireStorageModule. You can use this module to quickly and easily store and serve user-generated content like photos and videos as well as monitor uploads and metadata associated with files.

Now that we know how the app was configured initially, we can take a look at the other Firebase features that are used.

Authentication

We use AngularFireAuth service to monitor the app authentication state. AngularFireAuth.auth returns an initialized firebase.auth.Auth instance, allowing us to log users in and out. The app demonstrates Sign-in capabilities using three providers: Facebook, Google, and Email.

Firebase user instance is kept for every provider linked to the user, and when a user is registered or signs in, that user becomes the current user of the Auth instance. The instance persists the user’s state so that refreshing the page or restarting the application doesn’t lose the user’s information.

We use signInWithRedirect method for both Facebook and Google providers, in order to sign in by redirecting to the sign-in page. Password-based account creation is used for the Email sign-in provider, createUserWithEmailAndPassword and signInWithEmailAndPassword are the methods responsible for the user account creation and sign-in.

Password-based account view

I recommend the official Firebase docs for more detailed information on authentication and user lifecycle.

Real-time Database Actions

Firebase offers two cloud-based, client-accessible database solutions, and we are using Firebase’s original database — Realtime. Check out the differences between Realtime and Cloud firestore on the official documentation page.

AngularFireDatabase and AngularFireList services are used in the Portfolio app to retrieve, save and remove data easily.

AngularFireDatabase can be injected through the constructor of a component or @Injectable() service. In our case we use the second approach:

Data is retrieved through the AngularFireDatabase service, which fills Observable list of BlockItems. AngularFire provides methods like snapshotChanges() that returns Observable of data as a synchronized array. It is very handy if you want to limit event actions, like added, changed, removed and moved. By default, it listens to all four, however, you may only be interested in one of these events and you can specify which of them you’d like to use. In our application, we are subscribed to all of them.

Adding a new item, updating an existing one, or removing it from the list is achieved by using push(), update() and remove() methods.

Each data operation method returns a promise, although we don’t need to use the completion promise to indicate success because the real-time database keeps the list in sync.

Observables

CoinItem service

Cryptocompare API service manages async data and emits multiple values at a time with Observables. We use [HttpClient get(](https://angular.io/guide/http))method to request the data from the resource and subscribe to it, in order to transform it to Observable Array of CoinItem objects, which will be used later by our igxGrid, igxList, and igxCard components.

Rx.js allows us to cache the result of the HTTP Request. We retrieve this data initially, cache it and use the cached version during the application’s lifetime. The combination of publishReply(1, 300000) and refCount() does the following.

publishReply(1, 300000) tells Rx to cache the latest emitted value and to stay valid for 5 minutes. After that time, it will invalidate the cache.

refCount() tells Rx to keep the Observable alive as long as there are any Subscribers.

Now after we subscribe to the Coins list, the result will be cached, and we won’t need to make another HTTP Request.

BlockItem service

Portfolio Crypto Coins data is ensured by getItemsList() method that returns Observable BlockItem array to which the igxGrid component is subscribed to. Only authenticated users can use this service because of the AngularFireList that we manipulate is associated with unique user ids.

Visualize the data

For the visualization, we use UI Components from the Ignite UI for Angularlibrary. These components are responsible for data handling while providing access to custom templates and real-time updates, with intuitive API, by using minimal amount code.

igxGrid

Grids [data] property binding is used to pass the returned BlockItem array. Each <igx-column> represents a field of the object and it is used to define features like editing and sorting. The columns are templatable, and with the help of Angular pipes, we can declare display-value transformations in them easily. We use a decimal pipe to change the minimum number of integer digits before the decimal point.

The component provides straightforward event handlers and API for CRUD operations. Handlers like updateRow and deleteRow are implementing additional logic like AngularFireList manipulation and coin item restore logic with the igxSnackbar.

igxCard

Cards are used to provide general information of Crypto coins using CSS Flexbox layout. These Card components can be filtered with the igxFilter directive, which can be used to filter different data sources. igxFilter can be applied as a pipe or as a directive.

igxFinancialChart

The Chart offers multiple ways in which the data can be visualized and interpreted, once it is returned by the service. There are several display modes for price and volume, and in our case we use chartType=”candle”.

The financial chart component analyzes and selects data columns automatically:

• Date/Time column to use for x-axis
• Open, High, Low, Close, Volume columns or the first 5 numeric columns for y-axis

Theming

IgniteUI for Angular bases its component designs on the Material Design Principles and with just a few lines of code, we can easily change the colors, sizes, typography, and overall look and feel of our components.

Now that we’ve provided all base definitions needed for the igx-theme, and have configured the igx-dark-theme mixin, we need to only apply .light-theme and .dark-theme CSS classes somewhere at DOM element root level and toggle it on button click.

Result

Wrapping up

Everything is possible with the right tooling. We have created a Portfolio Web application using the full power of the Angular Framework, Firebase Authentication services, and Cloud Database store/synchronization.

You can find the GitHub repository and the actual portfolio application here.

Feel free to share in the comments below any questions that you have, suggestions as to what can be improved or changed in the app, or any problems that you’ve encountered while configuring your Firebase account or application.

Article Highlights:

• How to store private keys on the back end without security concerns
• How to properly design smart contracts and what to “decentralize”
• Decentralized and semi-centralized applications architecture examples
• How to deal with low-level stuff like network load and failures

It’s going to be big, let’s do it!

Decentralized Programs and Blockchain

Despite the fact that blockchain is facing a lot of adoption and regulation difficulties today, it’s a kind of technology which is here to stay, whether it’s blockchain, hashgraph, tempo or any other distributed ledger technology still to come, regardless of the algorithm.

The main value that blockchain and other similar technologies bring can be generalized as follows: they allow people to write and run programs which, practically, cannot be changed after creation nor tampered with during execution. In other words, these programs always run as designed, and no single party can influence their behavior.

This definition is valid for many cryptocurrencies that exist today if we consider them as programs that define how coins can be transferred back and forth. This also explains why cryptocurrencies and many kinds of tokens have real value: they cannot be generated out of thin air, by their defined “underlying programs”.

Ethereum/EOS/Tron/… platforms, in contrast to Bitcoin, implement a more complex program layer, which in turn implements the execution environment allowing anyone to write their own decentralized programs on top of the platform. This user-defined programs always run as designed, without any exceptions, and their security is guaranteed by the platform.

Decentralized Applications

These secure and unchangeable programs running on a decentralized network in combination with traditional front-end and back-end technologies are what we call decentralized applications (ÐApps) today. Through some of them can be semi-centralized, a major part of activities in the truly decentralized application should happen out of a central party’s control.

If someone asked me to draw how DApps work today, I would probably have drawn this

To imagine what we call decentralized applications today, take any existing centralized web resource like YouTube or Instagram as an example and imagine that instead of a password-protected centralized account you have your “crypto identity” bound to the web/mobile resource.

That’s what Wallet Software provides you. The private key from this identity (a secret, having which, you can act on behalf of this identity) is stored on your local device and never goes online, making no one able to control this identity but you. With this identity, you can perform different actions in both centralized (web resource controlled by a central authority) and decentralized (which is a different network from the traditional www, the goal of which is to eliminate the central authority) networks, using the website as an access point and/or as a graphical user interface. The whole point of this “crypto identity” is that your actions are cryptographically secured, and no one is able to change what have you signed nor your signature.

Today, the computational and storage capabilities of fault-tolerant decentralized networks like Ethereum, EOS or Tron are limited. If they were scalable, we could use decentralized networks to store the whole decentralized application, including its graphical user interface, data and business logic. In this case, we would call these applications truly decentralized/distributed.

However, because those networks are not scalable today, we combine different approaches to achieve the maximum decentralization level for our applications. The “traditional” back end as we know it isn’t going anywhere. For instance:

• We use back end to host front end for a decentralized application.
• We use back end for integrations with any other existing technologies and services. Real, world-class applications cannot live in an isolated environment.
• We use back end to store and process anything big enough for a decentralized network (blockchain in particular). Practically, the whole application and its business logic are stored somewhere in the world, excluding the blockchain part only. Not to mention, IPFS and similar storage layers cannot guarantee the accessibility of files, hence we cannot rely on them without hosting the files ourselves either. In other words, there’s always a need for a dedicated running server.

There’s no way of building a secure and partially decentralized application without using a solid back end as of today, and the whole point of this article is to explain how to do this right.

(De)centralization and Tokens

It so happens that almost all decentralized applications today are built around so-called tokens — custom-built (or just simply cloned) cryptocurrencies that drive a particular decentralized application. Tokens are simply a programmable currency or assets, that’s it.

While token smart contracts determine how users can transfer tokens, application smart contracts can extend everything missing in token smart contracts. Both smart contracts run on top of decentralized networks

Usually, a token is a “smart contract” (a custom program) written on top of the decentralized platform like Ethereum. By owning some tokens you are basically able to get different services on a web resource or mobile app, and trade this token for something else. The key point here is that the token lives on its own and it is not controlled by a central authority.

There are many examples of applications that are build around tokens: from numerous collectible games like CryptoKitties (ERC721 tokens) to more service-oriented apps like LOOM Network, or even browsers like Brave and gaming platforms like DreamTeam (ERC20-compatible tokens).

Developers themselves determine and decide how much control they will (or won’t) have over their applications. They can build the whole application’s business logic on top of smart contracts (like CryptoKitties did), or, they can make no use of smart contracts at all, centralizing everything on their servers. However, the best approach is somewhere in the middle.

Back End for Decentralized Networks

From a technical point of view, there has to be a bridge that connects tokens and other smart contracts with the web/mobile application.

In today’s fully decentralized applications, where clients interact with smart contracts directly, this bridge is narrowed down to a JSON RPC API capabilities of public APIs or node pools like Infura, which in turn are forced to exist because of the fact that not every device can run and support its individual network node. However, this API provides an only basic and very narrow set of functions, which barely allow making simple queries nor efficiently aggregate data. Because of this, eventually, custom back end kicks in, making the application semi-centralized.

The whole interaction with the decentralized network can be narrowed down to just one or two points, depending on the application needs:

1. Listening to the network events (like token transfers) / reading the network state.
2. Publishing transactions (invoking state-changing smart contract functions like token transfer).

Implementing both of these points is quite tricky, especially if we want to build a secure and reliable back-end solution. Here are the main points which we are going to break down below:

• First of all, in Ethereum, events retrieval is not production-ready out of the box. Because of multiple reasons: network nodes can fail while fetching a large number of events, events can disappear or change because of network forks, etc. We have to build an abstraction layer to sync events from the network and guarantee their reliable delivery.
• The same for transaction publishing, we have to abstract Ethereum’s low-level stuff like nonce counters and gas estimations, as well as transaction republishing, providing a reliable and stable interface. Moreover, transaction publishing implies using private keys, which requires advanced back-end security.
• Security. We are going to take it seriously and face that it’s impossible to guarantee that private keys won’t ever be compromised on a back end. Luckily, there is an approach to designing a decentralized application without even a need for back-end accounts to be highly secured.

In our practice, all of this made us create a robust back-end solution for Ethereum which we name Ethereum Gateway. It abstracts other microservices from Ethereum’s fun and provides a reliable API to work with it.

As a fast-growing startup, we cannot disclose the complete solution (just yet) for obvious reasons, but I am going to share everything that you need to know to make your decentralized application work flawlessly. However, if you have any specific questions or inquiries, feel free to contact me. Comments to this article are much appreciated as well!

_Back End Monitoring for Ethereum. The monitor demonstrates activities mainly regarding our [recurring billing feature](https://github.com/dreamteam-gg/smart-contracts/blob/master/contracts/token/TokenRecurringBilling.md" rel="noopener" target="blank" title=") (though you can see peaks happening each hour).

Decentralized Applications Architecture

This part of the article highly depends on the needs of a particular decentralized application, but we will try to sort out some basic interaction patterns on top of which these applications are built (ÐPlatform = Decentralized Platform = Ethereum/EOS/Tron/Whatever):

Client ⬌ ÐPlatform: fully decentralized applications.

The client (browser or mobile application) talks to the decentralized platform directly with the help of Ethereum “wallet” software like Metamask, Trust or hardware wallets like Trezor or Ledger. Examples of DApps build in such manner are CryptoKitties, Loom’s Delegated Call, crypto wallets themselves (Metamask, Trust, Tron Wallet, others), decentralized crypto exchanges like Etherdelta and so on.

ÐPlatform ⬌ Client ⬌ Back End ⬌ ÐPlatform: centralized or semi-centralized applications.

The client interaction with the decentralized platform and the server has little in common. The good example of this is any (centralized) crypto exchange today, like BitFinex or Poloniex: the currencies you trade on exchanges are simply recorded in the traditional database. You can “top up” your database balance by sending assets to a specific address (ÐPlatform ⬌ Client) and then withdraw assets after some actions in the app (Back End ⬌ ÐPlatform), however, everything you do in terms of a “ÐApp” itself (Client ⬌ Back End) does not imply your direct interaction with the ÐPlatform.

Another example is Etherscan.io, which uses semi-centralized approach: you can do all useful decentralized actions there, but the application itself just doesn’t make sense without their comprehensive back end (Etherscan continuously syncs transactions, parses data and stores it, ultimately providing a comprehensive API/UI).

Something in between: still, centralized or semi-centralized applications.

The above approaches combined. For example, we can have an application which provides various services in exchange for crypto, allowing you to log in and sign information with your crypto identity.

Hopefully, the interaction pattern of fully decentralized applications (Client ⬌ ÐPlatform) does not raise any questions. By relying on such amazing services like Infura or Trongrid one can simply build an application which doesn’t require a server at all. Almost all client-side libraries like Ethers.js for Ethereum or Tron-Web for Tron can connect to these public services and communicate with the network. However, for more complex queries and tasks, you may need to allocate your own server anyway.

The rest of the interaction patterns which involve back end make things more interesting and complex. To put all these in a picture, let’s imagine a case where our back end reacts to some event in the network. For example, the user publishes an allowance transaction which gives us permission to charge them. To make a charge, we have to publish the charge transaction in response to the emitted allowance event:

An example flow of server’s reaction to the user’s action in the decentralized network

From the back end point of view here’s what happens:

1. We listen to a particular network event by continuously polling the network.
2. Once we get an event, we perform some business logic and then decide to publish a transaction in response.
3. Prior to publishing the transaction, we want to ensure that it will likely be mined (in Ethereum, the successful transaction gas estimation means there are no errors against the current network state). However, we can’t guarantee that the transaction will be mined successfully.
4. Using a private key, we sign and publish the transaction. In Ethereum we also have to determine the gas price and gas limit of the transaction.
5. After publishing the transaction, we continuously poll the network for its status.
6. If it takes too long and we can’t get the status of the transaction, we have to re-publish it or trigger a “fail scenario”. Transactions can be lost for various reasons: network congestion, dropping peers, network load increase, etc. In Ethereum, you can also consider re-signing a transaction with a different (actual) gas price.
7. After we finally get our transaction mined, we can perform more business logic if needed. For example, we can notify other back end services about the fact of the transaction being completed. Also, consider waiting for a couple of confirmations prior to making final decisions regarding the transaction: the network is distributed and hence the result can change in a matter of seconds.

As you can see, there’s a lot going on! However, your application may not require some of these steps, depending on what you are trying to achieve. But, building a robust and stable back end requires having a solution for all the problems mentioned above. Let’s break this down.

Decentralized Applications Back End

Here I want to highlight some of the points which arise most of the questions, namely:

• Listening to network events and reading data from the network
• Publishing transactions & how to do it securely

Listening to Network Events

In Ethereum, as well as in other decentralized networks, a concept of smart contract events (or event logs, or just logs) allows off-chain applications to be aware of what is happening in the blockchain. These events can be created by smart contract developers at any point of the smart contract code.

For example, within the well-known ERC20 token standard each token transfer has to log the Transfer event, thus letting off-chain applications know that there is a token transfer happened. By “listening” to these events we can perform any (re)actions. For instance, some mobile crypto-wallets send you a push/email notification when tokens are transferred to your address.

In fact, there’s no reliable solution for listening to network events out of the box. Different libraries allow you to track/listen to events, however, there are many cases when something can go wrong, resulting in lost or unprocessed events. To avoid losing events, we have to build a custom back end, which will maintain the events sync process.

Depending on your needs, the implementation can vary. But to put you in a picture here is one of the options of how can you build reliable Ethereum events delivery in terms of microservice architecture:

Reliable delivery of Ethereum events to all back end services

These components work in the following way:

1. Events sync back end service constantly polls the network, trying to retrieve new events. Once there are some new events available, it sends these events to the message bus. Upon successful event submission to the message bus, as for blockchain, we can save the last event’s block in order to request new events from this block next time. Keep in mind that retrieving too many events at once may result in always failing requests, so you have to limit the number of events/blocks you request from the network.
2. The message bus (for example, Rabbit MQ) routes the event to every queue which was set up individually for each back end service. Prior to event publishing, events sync back end service specifies the routing key (for example, a smart contract address + event topic), while consumers (other back end services) create queues which are subscribed for particular events only.

As a result, each back end service gets only those events it needs. Moreover, the message bus guarantees the delivery of all events once they are published to it.

Of course, you can use something else instead of the message bus: HTTP callbacks, sockets, etc. In this case, you’ll need to figure out how to guarantee callbacks delivery yourself: manage exponential/custom callback retries, implement custom monitoring and so on.

Publishing Transactions

There are a couple of steps we have to perform in order to publish a transaction to the decentralized network:

1. Preparing the transaction. Along with transaction data, this step implies requesting the network state in order to find out whether this transaction is valid and is going to be mined (gas estimation in Ethereum) and the transaction’s sequential number (nonce in Ethereum). Some of the libraries try to do this under the hood, however, these steps are important.
2. Signing the transaction. This step implies the usage of the private key. Most likely, here you’ll want to embed the custom private key assembly solution (for instance).
3. Publishing and republishing the transaction. One of the key points here is that your published transaction always has a chance to get lost or dropped from the decentralized network. For example, in Ethereum, the published transaction can be dropped if the network’s gas price suddenly increases. In this case, you have to republish the transaction. Moreover, you may want to republish the transaction with other parameters (at least with higher gas price) in order to get it mined as soon as possible. Thus, republishing the transaction can imply re-signing it, if the replacement transaction wasn’t pre-signed before (with different parameters).

The above points regarding Ethereum transaction publishing visualized

By utilizing the above approaches you can end up building something similar to the thing which is presented in the sequence diagram below. On this particular sequence diagram, I demonstrate (in general!) how the blockchain recurring billing works (there’s more in a linked article):

1. The user executes a function in a smart contract, which ultimately allows the back end to perform a successful charge transaction.
2. A back end service responsible for a particular task listens to the event of charge allowance and publishes a charge transaction.
3. Once the charge transaction is mined, this back end service responsible for a particular task receives an event from the Ethereum network and performs some logic (including setting the next charge date).

_The general sequence diagram of how [blockchain recurring billing](https://hackernoon.com/payments-of-tomorrow-decentralized-recurring-billing-47d126d895fd" rel="noopener" target="blank" title=") works, demonstrating the interaction between back-end services and Ethereum network

Back End Security & Smart Contracts

Transaction publishing always involves using a private key. You may be wondering if it is possible to keep private keys secure. Well, yes and no. There are numerous complex strategies and different types of software which allow storing private keys on the back end quite securely. Some private key storage solutions use geo-distributed databases, while others even suggest the use of special hardware. However, in any case, the most vulnerable point of a semi-centralized application is where the private key is assembled and used to sign a transaction (or, in case of special hardware, a point of triggering a transaction signing procedure). Hence, theoretically, there’s no 100% reliable solution which will enable bullet-proof protection from compromising stored private keys.

Now think this way. In many cases, you don’t even need to secure private keys on the back end that often. Instead, you can design smart contracts and the whole application in such a manner that a private key leak won’t affect their usual behavior. With this approach, it doesn’t matter how authorized accounts interact with the smart contract. They’re just “triggering” a smart contract to do its usual job, and the smart contract itself performs any required validation. I call it the “operational accounts pattern”.

Operational accounts pattern for decentralized applications, where you don’t need military-grade security for your back-end accounts

This way, in case of emergency:

• The only thing the attacker can steal is a tiny amount of Ether (as of Ethereum) deposited to the operational accounts for transaction publishing
• The attacker won’t be able to harm the smart contract logic nor anyone who is involved in the process
• Compromised operational accounts can be quickly replaced with other ones, however, this requires either the manual replacement (generating new accounts, and reauthorizing accounts in all smart contracts) or developing an additional solution which will do all the magic with a single transaction from a super-secure (hardware or multi-sig) master account.

For instance, in our recurring billing for Ethereum solution, no matter what happens on a back end, the recurring billing smart contract is designed in such a manner that we have a whole month of time for replacing the compromised accounts if any of them are compromised.

But still, if you want to get your back end private key storage as secure as possible, you can try using Vault with a great plugin for Ethereum which stores and manages Ethereum accounts (also, keep an eye on our open-source modules — we are about to release something similar soon). I am not going to dive deep into the details here, though you can visit the linked projects and learn from there yourself.

This isn’t even all I have to say. However, this article turned out to be much longer than I expected so I have to stop. Subscribe to my Medium / other networks if you’re interested in software, crypto, travel tips or just want to follow something interesting. Hope I’ve provided a big valuable piece of information and you’ll find it useful. Feel free to comment and spread this article!

As the interest for blockchain projects and cryptocurrencies is exponentially growing, OmiseGO appears to be one of the strongest and most exciting projects out there. Still, as it involves fairly complex notions, it is hard for the beginner looking for an introduction to find a clear and complete guide: OmiseGO’s website provides all necessary documents, and especially the “white paper”, an in-depth explanation of the whole system, but although being an extremely well thought and precise document, it would be a lie to pretend it’s not a hard read at first sight.

There are also some good quality reviews already, but while they can be very useful, they usually focus on one specific point of the matter, such as commercial partnerships, without taking the time to introduce the whole of the project to someone that would be completely new to it.

So I decided to write the comprehensive guide that would take everything from the start and be clear for anyone to read, while at the same time exposing everything in the most precise and accurate way, in order to give this very ambitious project the wide audience and understanding it deserves.

As I’m taking things back from the basics, if you feel like you are already clear about some points, feel free to skip them and directly move to the points that interest you. I have tried to give a clear architecture to this article, clear titles and an introductive summary, so that you can browse easily through this guide if you don’t want to read it from the beginning to the end.

Please note that whatever you read in this guide, it is made only for explanational purpose, and is not in any case an investment advice: I am not entitled to this, I don’t wish to, and the choice one makes with his or her own money is his or her own choice. Investing in any project and especially in the crypto world is always a high risk operation, and I have no recommendation to make about it. Even the part titled “Why invest in OmiseGO” is to be considered a mere exposition of what can be the reasons to invest in the project if one chooses to, but not an advice pretending you should, or should not.

I’m only trying to clearly explain what OmiseGO is, what it is building, and what it can be in the future, while answering in a same article to many questions I’ve seen and answered separately on dedicated forums.

This article will cover the following points:

1) The company
What is Omise?
What is OmiseGO?
Who is the team?
How did Omise launch OmiseGO?

2) The project
A. Basics: Blockchain / Ethereum
How do internet services work without a blockchain?
What are the problems with the traditional model?
What is a blockchain?
What is Ethereum?
B. OmiseGO
What real-world problem does OmiseGO want to solve?
What customers is OmiseGO targetting?
What is OmiseGO building?
What is the OmiseGO blockchain?
What is the Decentralized Exchange (DEX)?
What is the OmiseGO Wallet?
What is the white-label wallet SDK?
What is the use of the OMG token?
C. Interactions with other projects
How will Ethereum and OmiseGO interact?
What is Plasma?

3) Partners and investors
A. Countries and Banks

1. Thailand
2. Japan
3. Singapore and Thailand
   B. Private partners and investors
4. TrueMoney
5. Mac Donald’s Thailand
6. Toppan Printing
7. Global Brain
8. Discussion phase: Greylock Partners
   C. OmiseGO adopters

4) The future
A. OmiseGO’s future
What will happen between Omise and OmiseGO?
What is OmiseGO’s roadmap?
B. Why invest in OmiseGO

5) Frequently Asked Questions
What will be the network’s fees’ amount?
What will be the minimum amount of OMG coins required for staking?
Is OMG an ERC20 token?
Will the OMG token be replaced by another token in the future?
Where to store OMG tokens?
Where to buy OMG?

1) The company

What is Omise?

Omise is a real-world company established since 2013 in Thailand, Japan, Singapore and Indonesia. It provides an online payment solution already used by thousands of customers: these customers are merchants, using the Omise payment solution to sell their products or services to their own customers.

Omise have been featured in 2016 by Forbes Thailand as « Fintech rockstars », and awarded « Digital startup of the year » by Thailand’s Prime Minister.

What is OmiseGO?

OmiseGO is an extension of Omise, born in 2017 to leverage the blockchain technology to propose a whole system that aims to revolutionize the way people take control of their financial and valuable assets and exchange them with each other, by providing a secure and completely open way to do so without boundaries and without depending on a third-party.

Who is the team?

Jun Hasegawa is Omise and OmiseGO’s CEO, and Donnie Harinsut is Omise and OmiseGO’s COO. Joseph Poon, who is co-author of the Lightning Network and co-author of Plasma, is OmiseGO’s principal author, and notable members of the advisors’ team include Vitalik Buterin, founder of Ethereum, and co-author of Plasma, Gavin Wood, co-founder of Ethereum, Jae Kwon, creator of Tendermint and Cosmos Network, Vlad Zamfir, Ethereum’s Casper Research Lead, Julian Zawitowski, founder of Golem, and Thomas Greco, member of Ethereum, the Cosmos Network and Streamr.

Thomas Greco, Vansa Chatikavanij, Gavin Wood, Vitalik Buterin, Donnie Harinsut, Jun Hasegawa

How did Omise launch OmiseGO?

Omise had planned an ICO to launch their OmiseGO project. An ICO is an Initial Coin Offering, a kind of fundraising that is typically used for blockchain projects, where a company or project sells coins for a limited time at very special price, which is an incentive for investors who believe in the project and expect it to take value in the future, and allows the company to raise funds.

Usually, an ICO stops when the company reaches its hard cap, which is the maximum amount of money they want to raise through the ICO, or to say it the other way, the maximum amount of tokens they want to sell through the ICO. But ICOs are usually preceeded by a private sale for selected investors, also at a special price, and OmiseGO are famous for having reached their 25 million USD hard cap through the private sale, which means there wasn’t even a public ICO. They could have made an ICO anyway to raise more funds, and had over 100 million USD of interest for pre-ICO sale only, but they decided to stop once reached the needed funds for the project. Which, as a side-note, can be considered a fair move and a hint for trust.

2) The project

A. Basics: Blockchain / Ethereum

How do internet services work without a blockchain?

The traditional way things work without a blockchain, is the centralized database model. A company owns a private database, which is a library of data, stocked on a computer or on many computers called servers. This company also provides a public website, that people can access through the internet, thanks to the TCP/IP protocol, that allows a computer to connect to one specific server (or collection of servers) when typing in a certain address. For instance, typing in http://www.facebook.com will take you to Facebook’s website, meaning that thanks to the TCP/IP protocol, your computer will connect to Facebook’s servers, and only to these servers, when you type in facebook’s http address.

And when the user requests an action on a certain website’s interface through his browser, for instance when clicking on a link or filling in a form, the website will look for the relevant information (for instance: next page’s content) on its server, in other words, inside its private database, and deliver these informations on the user’s screen. And if necessary, the website will also update its database informations according to the user’s actions, for instance in the case of a user profile’s creation, edition or deletion.

In this model, the company owns a database, that is both, first, the collection of programmatic instructions that are the technical matrix of what users see on their screen, in other words the rules that define actions allowed by the website, and second, the library containing every data used by the website, for instance images used on the website, and every data users might enter in the website such as their identity information, profile picture, search and browsing history, payment information, and any information you might be giving when using a certain website.

_Image source [Infomotions.com](http://infomotions.com/musings/waves/clientservercomputing.html" rel="noopener" target="blank" title=")

What are the problems with the traditional model?

There are 3 main problems with the traditional centralized database model:

• The first problem is security: if a hacker succeeds in breaking the database’s security (and sometimes they do), a lot of sensitive content can leak and compromise users’ safety or privacy.

• The second problem is privacy, meaning the use that the website makes of people’s personal data: although this depends on every website’s policy, a website containing users information on its servers can sell these information to third parties, either anonymously (big data) either namely, whether the information will be used for direct custom marketing (most commonly), or for personal or industrial spying.

• Finally, the third problem, that includes the first two ones and also goes beyond them, is that, whatever the service provider is, such as a commercial company, a bank, a governmental office, and whatever the way they intend to treat people’s data, one thing that is common to any of these structures when using their services, is the need of trust: the users trust them, they give them sensitive information, assuming and hoping that the service will not do anything with their data that they would not want to, and that would compromise their privacy or put them in danger. This goes for the company as a whole (you trust the company), and it goes for the company workers: you trust that no malicious individual is part of the company’s team and has access to your data.

This trust system also means that the user doesn’t have the control on his own data, and instead, delegates this control to a third party (the company, bank or service), that he decides to trust enough to use (an online marketplace), or that the society strongly incites him to use (a bank).

What is a blockchain?

In two words, a blockchain is a decentralized database that is also a network.

What does that mean?

The traditional system is basically made of 2 entities: the user’s client (his computer and internet browser or connected application), and the website’s server / database that communicates with the client.

And if 10 000 users connect to the same website, you still have, 10 000 clients on one side, and 1 database on the other side (or a collection of many databases when the website is big, but they still equal to one centralized database at the end). And the information (the data) moves in 2 binary ways: from a client to the server, or from the server to a client.

Now imagine that the website doesn’t own a private database, and that, instead, each of the 10 000 clients, additionally to being a client (a user), also owns an identical copy of the database.

_Image source [Seats2meet.com](https://magazine.seats2meet.com/more-about-blockchain/" rel="noopener" target="blank" title=")

Imagine that if a hacker is hiding inside this 10 000 users and want to fallaciously delete or add or edit an information in the database at his own profit (for instance: add a money transfer from a victim user’s account to his own account), his own copy will become different from the other 9999 copies, so his database copy will be automatically rejected and his fraud attempt will be rejected as well.

Imagine also that the database is not anymore made of lines and rows and entries, where you can edit the entries, like in a traditional database, but of blocks of information that vertically align and add one to the other through time, and that once confirmed and put into the line of blocks (the block chain), not any block can ever be edited or erased in the future.

Finally, imagine that to add one new block to the chain in order to validate it, it has to be accepted both horizontally, meaning it has to be confirmed by all the users who own a copy of the database (or a sufficient number of random users), and also vertically, meaning that to be confirmed as block 3456 of the chain, it has to provide an extraordinary complicate cryptographic proof, without which it won’t be able to hook to block 3455, and won’t be able to be added to the chain.

This, is blockchain as a decentralized database: the database is now identically shared by thousands of computers, and not a single line can be erased or changed in the database (ever), and not a single line can be added without providing a very specific proof and having it confirmed by these thousands of computers that will also check that it matches vertically with their previous block. The result is that the hacker that had the ability to break a centralized database’s security and steal its sensitive content, would now have to break extremely complicate cryptographic barriers but also break the doors to thousands of computers at the very same time, to modify each of the thousands of existing copies of the database: this is why the blockchain is considered virtually unbreakable. To get deeper into this matter and learn about hashes and nonces, you can watch this very clear and interesting video by Anders Brownworth here.

_Watch Anders Brownworth’s [video](https://anders.com/blockchain/" rel="noopener" target="blank" title=") and give a meaning to these colourful boxes and numbers

And blockchain as a network simply means that all these computers owning their own identical copy of the decentralized database, are also all running a certain application, thanks to which they are all linked together, and constitute a big network. Each point of this network, meaning each computer owning this database copy and running this application, is called a node, because, as in a physical net or web, it acts as the link and nodal point where several lines meet. And thanks to this nodes and lines horizontal architecture, where any node is virtually linked to any other node, the information (data) can travel, now not only in a binary way from a server to a client or a client to a server, but, as everyone is now both a client and server, from any node to any node. This data can be any type of information you can imagine, and this network structure, where any type of information can travel from any node to any other node, is blockchain as a network.

Then, users can also use applications running on this network without running a node themselves, and without owning their own copy of the database.

What is Ethereum?

Above the blockchain protocol, the term Ethereum both refers to the Ethereum blockchain and to the Ethereum application layer running on this blockchain. The Ethereum blockchain is a certain blockchain, meaning a certain network made of thousands of computers acting as Ethereum nodes. And, running on the Ethereum blockchain, the term Ethereum also refers to a supplementary application protocol layer, that developers can use to develop their own applications on the Ethereum network.

Ethereum has also popularized the concept of smart contracts, that define rules between 2 participants, and thanks to which a certain transaction happens when and only when the parameters accepted by both participants are met, without allowing one of the 2 participants to change the terms of the contract without the other’s agreement: which is a guarantee of technical and legal transparency. The contract can be financial, or happen on any other level. In the same time, the Ethereum protocol also includes its own token, Ether (ETH).

_Image by Maria Kuznetsov, source [Coindesk.com](https://www.coindesk.com/information/what-is-ethereum/" rel="noopener" target="blank" title=")

In other words, the term blockchain both refers to a certain type of protocol and process between computers, and to one particular existing network that is built based on the blockchain protocol. And to develop a blockchain application (because you want your application to leverage the benefits of the blockchain protocol such as decentralization, safety and privacy), you need to create a certain blockchain, and you need to develop an application on it. Both are complicate and costly operations, because the blockchain ecosystem and development is still a sort of “cognitive wild wild west”. In this wild wild west, Ethereum comes to take everyone by the hand, by providing a usable and efficient blockchain, and a certain suit of development tools to build on: a JavaScript inspired programming language called Solidity, and a development framework based on Solidity, that developers can use to develop and run their applications on the Ethereum blockchain.

The reason of Ethereum’s popularity lies in the Ethereum blockchain’s robustness and quality, in the development of the smart contracts process, and in the fact that Ethereum as an application layer allows developers to develop any kind of application they want, skipping the blockchain construction process, opening the door to a brand new world of blockchain based applications with a reduced development cost and learning curve. Ethereum is already active (first version July 2015) and still on development, and many observers consider it might bring a considerable paradigm shift, and change the way we know the world and interact with others in a same way the internet has changed it a couple of decades ago. It is also part of the blockchain and computer culture to know that Ethereum has been founded by young Vitalik Buterin.

B. OmiseGO

What real-world problems does OmiseGO want to solve?

OmiseGO is addressing 2 types of problems:

• First problem or fact is that hundreds of million people in Asia, and 2 billion people worldwide, are unbanked. They don’t have access to a bank account, and can’t either use one in their daily lives, either remotely send or receive money easily except using costly solutions (which can often be a problem for immigrant workers aiming to send money to their family). On the other hand, especially Asia shows an exceptional internet penetration rate: many unbanked people, but more and more connected people.

OmiseGO wants to provide unbanked people with an easy, open solution allowing them to own, send, receive money on a dematerialized form, whatever currency or asset they want to send, and at a minimal cost.

_2016 map. Source [PaymentsCardsAndMobile.com](http://www.paymentscardsandmobile.com/addressing-unbanked-developing-countries/" rel="noopener" target="blank" title=")

• Second problem is what OmiseGO defines as « a fundamental coordination problem amongst payment processors, gateways and financial institutions »: meaning that the economical and financial world is full of closed networks, where it is possible to send money inside one very network, but much more difficult or costly to send cross-network money or values.

OmiseGO wants to provide users and merchants with a universal, decentralized solution, making it easy and costless to send money from any network to any network, agnostically among currencies or asset types, and countries and juridictions.

As a side effect, such a network which by design equally allows to exchange fiat money (money emitted by nations), cryptocurrencies (computer created digital money), on any asset or value (loyalty points) through a blockchain secure network, easy to use and with minimal cost, should also likely increase the use of cryptocurrencies in people’s daily life.

What customers is OmiseGO targetting?

OmiseGO is targetting 2 types of customers:

• First type are individual users, and especially at first in South-East Asia, to provide them with an easy daily solution that can act as a positive substitute to a bank account, allowing them to keep, send, receive money, easily, safely, quickly and at small cost, on an open network, without depending on banks’ acceptance, and without relying on bank as a trust third party, allowing them to take control of their own financial autonomy

• Second type are merchants and wallet providers, and more generally Electronic Payment Providers (EPPs), allowing them to propose solutions with which their customers can seamlessly keep, send, receive and exchange any type of values from any network to any other network, giving them much more freedom than they currently have, and at a much smaller cost.

_If you have nothing better to do on Philippines’ Panglao Island, you can use your OmiseGO wallet / Photo Reinhard Dirscherl, Getty, source [Travel + Leisure](http://www.travelandleisure.com/slideshows/best-secret-beaches-on-earth#panglao-island-phillippines" rel="noopener" target="blank" title=")

What is OmiseGO building?

OmiseGO is building a full decentralized system to enable value exchange in real time and in peer-to-peer on an Ethereum-based blockchain, whatever the value type is (fiat money, cryptocurrency, any asset or any countable value such as mileage or loyalty points), and agnostically accross juridictions.

• This full system will take place on the OmiseGO blockchain (network), and will include on this blockchain:

• A Decentralized Exchange (DEX), a liquidity provider mechanism, a clearinghouse messaging network and an asset-backed blockchain gateway

• The OmiseGO wallet

• A white-label wallet Software Development Kit (SDK)

• The OmiseGO network’s own token: the OMG token

What is the OmiseGO blockchain?

OmiseGO is building its own network, the OmiseGO blockchain. The OmiseGO blockchain will not be owned by the OmiseGO company as its own property, but will be an open and permissionless network belonging to all those using it. The operations happening using the OmiseGO products (these products are the DEX, the OmiseGO wallet and the wallets or applications built with the OmiseGO SDK) will happen partly on the OmiseGO blockchain, and partly on the Ethereum blockchain. How the operations will be distributed between these 2 networks is explained below in « How will Ethereum and OmiseGO interact? ».

_Source [OmiseGO](https://omg.omise.co/" rel="noopener" target="blank" title=")

What is the Decentralized Exchange (DEX)?

In order to be able to send and receive any currency or asset on the network, the OmiseGO blockchain will include a decentralized exchange (DEX) allowing values to be traded in real-time for other values.

This way, Electronic Payment Providers using the OmiseGO network can allow their customers to send and receive payments not only inside the EPP’s own network, but also cross-network: the OmiseGO blockchain will not only act as blockchain in itself, but also as hub to which other blockchains can hook, and that can hook to other blockchains, breaking the traditional boundaries between various payment channels. In other words, OmiseGO will allow eWallet interchange, while the OmiseGO blockchain will keep a ledger of every eWallet service’s current balance.

OmiseGO blockchain will also include a decentralized orderbook and trading engine. Direct crosses between various eWallets’ own fiat currencies may be too numerous to be treated fast enough using the blockchain: this is why it is expected that EPPs will hold a certain liquidity pool for small amount transfers for their most popular destinations. And for higher amounts transfers, that are the real goal and upside of the OmiseGO network, in order to create a liquid market and allow for fast trades and transfers, some ETH will be bonded into a smart contract on the OmiseGO chain (or Bitcoin-like tokens will be bonded into bonded clearinghouses), that will allow any fiat or cryptocurrency to be traded with ETH.

This means that, for instance, if A wants to send yens to B, but B wants to receive dollars, A will send yens, the yens will be traded for ETH, and then the ETH will be traded for dollars, and dollars will arrive to B.

However, using ETH as a reference currency for trading is not compulsory, but it will be more efficient and faster to use cryptocurrencies as pairs’ reference currencies.

In order to scale the network, and to prevent liquidity pools to create centralization (liquidity pools are liquidities provided by the users to the network, to create a liquid network and fast trades, so if users own a huge amount of liquidity, they could come to take too much power on the network), a Lightning Network style construction, called Plasma and currently under development, will allow for offloading a lot of operations off-chain: every electronic payment provider (EPP) will set up a channel into an ETH smart contract for small transfers, allowing it to supply liquidity onto its own off-chain centralized network, without overwhelming the OmiseGO decentralized blockchain network with a too high number of small transactions.

It must finally be pointed that the OmiseGO network is not designed with the goal to be a high-volume low-value network, to handle a very high volume of micro-transactions, but with the goal of being « the preeminent high-value exchange and settlement platform ».

_Source [OmiseGO](https://omg.omise.co/" rel="noopener" target="blank" title=")

What is the OmiseGO wallet?

A wallet is essentially an application with which you can stock, send, receive money and value assets.

On the OmiseGO blockchain, as well as on various blockchain projects, a wallet, when it is opened (that is, when the application is launched) is also what makes your computer a node of the blockchain. Another way to say it, is that a blockchain is a network of open wallets, running on computers.

What is the white label wallet SDK?

A SDK is a Software Development Kit, also called a programming framework. If you know about React, Angular, Ruby on Rails, these are frameworks too. A SDK is a collection of pre-defined programming functions for a certain collection of purposes, allowing developers to develop applications in a much faster and efficient way than if they would have to code everything from scratch. For instance, the SDK provides a certain “do-this” function: behind this function are 1000 lines of code, that the programmer using the SDK won’t have to write, because he will just use the SDK’s “do-this” instruction. SDKs provide many “do-this” functions, each of them saving time and cost to developers and companies.

The white label wallet SDK built by OmiseGO will, as its name implies, be a framework for developers and companies to quickly and efficiently develop wallets for their own customers, and without any mandatory design or OmiseGO mention on the final product, as the SDK will just be a set of programming functions (many “do-this”). Any developer can develop and design his own product, just using the SDK to accelerate the process, save money and time, and avoid the painful process of building his own blockchain and the painful learning curve of fully understanding the complex blockchain model.

_Source [OmiseGO](https://omg.omise.co/" rel="noopener" target="blank" title=")

The OmiseGO white-label wallet SDK will be free to use for anyone, and every transaction happening through applications developed with the SDK, will automatically take place on the OmiseGO blockchain.

OmiseGO’s statement is that already existing major players will have an interest to develop their own blockchain and their own wallets, but that there is a long tail of medium and small size wallet providers coming soon on the financial and value transfer market, that would highly benefit OmiseGO’s SDK. Which would also consequently accelerate the adoption of blockchain and blockchain based wallets by a wide audience.

What is the use of the OMG token?

The OmiseGO wallet application will not only serve as a way to send and receive money.

In the blockchain, when a transaction happens (for instance, A wants to send money to B), the transaction is included in a « block », a collection of transactions, and for the block to be valid and be added to the block chain, it has to be confirmed by actors of the network, in other words, by nodes, in other words, by computers having their wallet open.

But it is not enough to have a wallet open: if your wallet is empty, you won’t be able to confirm any block. So how does it work?

Keeping a certain amount of OMG tokens on your wallet buys you the right to confirm blocks. (As a side-note, to increase the network’s security, it will be required that OMG validators also run a full node of the Ethereum network, that works using the same validation process.)

Now, why would you want to have that right?

Because the OmiseGO blockchain will work through the Proof of Stake system (PoS), meaning that every transaction happening on the OmiseGO blockchain will generate a small fee (of which the amount is still to be set), and many transactions will generate many small fees. If the number of transactions is sufficient, an immense amount of small fees can turn into a very important global amount. Keeping your tokens on your wallet is called staking them, and the Proof of Stake system means that:

• The network generated fees will be distributed among tokens holders (stakers).

• The more coins you stake (the more coins you hold on your wallet), the more fees you will receive proportionally to other stakers. A staker with 2000 OMG on his wallet will receive twice the amount received by a staker with 1000 OMG.

Passive income / Credit Don Rosa, Disney, Glénat

• If you are caught making a bad use of the network (cheating in any way, likely for your own benefit), all the tokens you were staking are burned, which means destroyed, which means: you lose money. You lose the amount you had paid to acquire these OMG tokens, you lose the value they had at this moment of time, and of course you lose the ability to receive fees from the neetwork.

So the reason you are paid more if you stake more coins, is because you take a bigger risk, should you would want to attack the system, and so it is considered that you will not want to attack it: the token acts as a bond. The more you stake, the more you can lose if you cheat, so the more you can be considered a trustful node, and the more financial compensation you receive for your blocks confirmation activity.

Hackers got caught, tokens got slashed / Credit Don Rosa, Disney

But if you know the Proof of Work system (PoW), which is used for Bitcoin, and currently on Ethereum too before their Proof of Stake system is ready, it is important to note that oppositely to Proof of Work, in the Proof of Stake protocol, knowing what node (what user) confirms a block, has no influence on who receives the fees. Only how much coins one stakes does matter. (Which also makes the Proof of Stake system an ecologically much less costly system than the Proof of Work system, where every machine spends huge amounts of energy competing to be the one that will confirm the transaction.)

This economic incentive is the reason why the more transactions will happen on the OmiseGO network, the more passive income will come to OMG holders, and so the more value the OMG token will take.

Additionally, the OMG token will be usable as a payment token with merchants accepting it.

C. Interactions with other projects

How will Ethereum and OmiseGO interact?

As said above, OmiseGO is building its own blockchain, but actually, not every operation will happen on the OmiseGO blockchain: everything that belongs to following OMG rules to decide what money goes where and what trading orders are executed in what manner, happens on the OmiseGO blockchain, but the final delivery happens on the Ethereum blockchain. Said differently, every decisional operation (clearing and settlement) happens on the OmiseGO chain, while the actual final money transfer is delegated to the Ethereum blockchain.

What is Plasma?

While the blockchain has many very positive aspects compared to the traditional centralized database model, it still has a scalability problem that needs to be solved: not too many transactions can happen very fast at the same time. Plasma is a solution co-developed by Joseph Poon and Vitalik Buterin, both key advisors of the OmiseGO project, that allows an extreme scalability, potentially billions of state updates per second, « state » being a sort of « snapshot of the data situation ». In plain English, it will make it possible to handle very fast an extremely high amount of transactions, making the OmiseGO network’s efficiency comparable to the Visa network’s efficiency.

OmiseGO will be the first project to implement the Plasma technology, but as Plasma is currently under development, it is worth noting that OmiseGO will be able to start without using Plasma at the beginning, and will use the Cosmos Network for the same purpose with intermediate scalability in a first phase, where the OmiseGO network will not be fully public yet (see below “What is OmiseGO’s roadmap?” for details).

_Cosmos Network’s logo. Source [Cosmos Network](https://cosmos.network/" rel="noopener" target="blank" title=").

3) Partners and investors

A. Countries and Banks

1. Thailand

Omise is a strongly Thailand implanted company, and quite naturally many things happen between Thailand and its 2016 « Digital Start-up of the year ».

• First, it is important to stress that Thailand Finance Ministry has launched a national e-payment master plan to promote electronic payment, with the goal to create a cashless society. It is only speculation until now to think that this is linked to the fact that Omise and Vitalik Buterin had a meeting with the Central Bank of Thailand, but whether it was linked or not and how, what matters is that Omise and OmiseGO’s main implantation country has announced this goal, that OmiseGO can be an excellent solution provider in this perspective, and that Thailand’s Ministry and the company seem in very good terms.

And, on a more concrete level, the Thai Ministry of Finance successfully launched use of Omise’s FacePay technology, allowing payments with facial recognition.

• Thailand has also launched PromptPay, a new interbank mobile payments system “to enable money transfers” between accounts from different banks with a solution “cheaper and easier than those offered by conventional banks”. Authorization in participation to PromptPay is given by the Finance Ministry, and one of the two banks consortiums that received this authorization is the Thai Alliance Payment System, that includes the Bank of Ayudhya (commonly referred to as Krungsri), that recently made a 30 million dollars strategic investment in OmiseGO.

It is worth reminding that a « strategic investment » made by a company A into a company B, is different from a plain « investment ». A regular investment means that company A expects company B’s growth, and expects to receive dividends from this growth. But a strategic investment means that company A expects personal growth, as a company, from company B’s growth. Which means here that the Bank of Ayudhya invested in OmiseGO because Bank of Ayudhya expects that, thanks to OmiseGO, Bank of Ayudhya itself will grow.

_Omise CEO Jun Hasegawa, Krungsri Finnovate MD Sam Tanskul, Omise COO and co-founder Donnie Harinsut. Source [Digital News Asia](https://www.digitalnewsasia.com/startups/krungsri-finnovate-leads-latest-funding-round-omise" rel="noopener" target="blank" title=")

It is, by so, at this time also still speculation but meaningful speculation, to expect that the Bank of Ayudhya, who has a 7 billion dollars market cap (see Forbes review here), might provide their users in the future with financial applications running on the OmiseGO network. And again, any transaction happening on the OmiseGO network, for instance through an application provided by a bank to its customers, will generate fees that will be distributed between OMG coin holders.

It can also be noted, even though it has less potential impact, that the other 4 banks constituting the Thai Alliance Payment System authorized to join the interbank PromptPay system, are also all supported by Omise’s current online payment system.

2. Japan

With Thailand, Japan is the other main country of implantation of Omise and now OmiseGO, as their CEO and COO are respectively Japanese (Jun Hasegawa) and Thai (Donnie Harinsut). And like Thailand, Japan is strongly considering moving to a more cashless society, and especially launching a digital currency before 2020’s Olympic Games. But there are more concrete informations:

• Krungsri Bank of Ayudhya, strategic OMG investor, belongs to Japan’s largest financial group, Mitsubishi UFJ, also referred to as MUFG. (J and G are not a typo.) MUFG holds assets of around 2.4 trillion USD, making it world’s 5th largest bank by total assets, and world’s second largest bank holding company with 1.8 trillion USD in deposits.

• SMBC, second largest bank in Japan, was an early investor in OmiseGO.

• OmiseGO is partnering with Credit Saison, third largest credit card company in Japan, affiliated with Mizuho, the third largest bank in Japan.

_MUFG headquarters. Photo [Wikipedia](https://commons.wikimedia.org/wiki/User:Kakidai" rel="noopener" target="_blank" title="">Kakidai, Source MUFG <a href="https://en.wikipedia.org/wiki/Mitsubishi_UFJ_Financial_Group" rel="noopener" target="blank" title=")

3. Singapore and Thailand

According to a Bloomberg article, « Singapore and Thailand are in discussions about connecting their national digital payment systems to forge an unprecedented regional alliance, as officials step up efforts to curb the use of cash. The link would bring together Southeast Asia’s first national digital-payment platforms, Singapore’s PayNow and Thailand’s PromptPay, said Naphongthawat Phothikit, director of payment systems policy at the Bank of Thailand. »

As mentioned above, PromptPay is Thailand’s interbank mobile payments system through selected authorized banks, including Krungsri Bank of Ayudhya, who recently made this 30 million dollars strategic investment in OmiseGO.

B. Private partners and investors

1. TrueMoney

• In Thailand, the 3 biggest e-payment services are Paysbuy, AIS (mPAY) and TrueMoney. Omise recently acquired Paysbuy, and TrueMoney is a partner and shareholder of OmiseGO.

OmiseGO’s Crowdsale document reads: “By integrating with OmiseGO, the TrueMoney digital wallet end-customers will be able to conduct real-time low-cost money transfers, cross border remittances, retail, and bill payments. They will also be able to interact with other digital wallet providers (“brands”) that subscribe to the OmiseGO network.”

What is TrueMoney:

• TrueMoney is a financial technology brand providing e-payment services in South-East Asia (SEA), and having Google and Alipay as partner payment platforms. They have offices in Thailand, Vietnam, Cambodia, Myanmar, Indonesia and the Philippines, and licenses to operate e-money in almost every Southeast Asian country. In Thailand, the platform includes TrueMoney Wallet, WeCard with MasterCard, TrueMoney Cash Card, Kiosk, Express, Payment Gateway and Remittance.

• TrueMoney are also connected to Thai interbank mobile payment system PromptPay explained above, through Siam Commercial Bank (SCB). Thanks to this TrueMoney / SCB partnership, “more members of the public can enjoy easy, convenient access to financial services via PromptPay, which has until now only been available via a bank account”, and SCB will allow TrueMoney’s 3 million customers to charge their PromptPay eWallet through SCB services: SCB Easy App, SCB Easy Net and ATMS.

• Founded in 2003, TrueMoney now belongs to Thailand-based Ascend Group, which is a spin-off of True Corporation and belongs to also Thailand based CP Group, which is, in Thailand, the sole operator of over 9000 of the 7/11 stores that allow the use of TrueMoney. It is, again, still speculation but meaningful speculation, to assume that OmiseGO partner TrueMoney might, at some point, provide their very numerous users with a convenient service leveraging the OmiseGO technology and generating fees on the OmiseGO network.

• Ant Financial, the Chinese company owning China’s digital payment giant Alipay, and belonging to the Alibaba Group, recently invested in Ascend Money from the Ascend Group, which is, according to OmiseGO’s CEO Jun own words, « [OmiseGO’s] investor / partner / supporter ».

Alipay already counts more than 500 million users, is starting to target the USA, and has already managed until 1 billion transactions a day.

2. Mac Donald’s Thailand

OmiseGO has announced a formal relationship with Mac Donald’s Thailand. No further details have been given yet, but it can likely mean that Mac Donald’s customers will be able to pay their orders using the OmiseGO wallet in Thai restaurants.

3. Toppan Printing

OmiseGO is collaborating with Toppan Printing to start offering a new type of advertising and purchase process, thanks to which scanning a QR code on an advertising medium, for instance a magazine, will automatically allow the customer to order the advertised product.

4. Global Brain

OmiseGO plans to launch an accelerator program in collaboration with Japan-based venture firm Global Brain, as well as multiple blockchain labs.

5. Discussion phase: Greylock Partners

OmiseGO recently met up with Greylock Partners, a leading venture capital Silicon Valley firm managing $3.5 billion USD, and working with companies such as Facebook, Instagram, AirBnB, and Coinbase.

C. OmiseGO adopters

Hubii Network, a decentralized content marketplace counting 50 million users, announced they had chosen OmiseGO as the obvious solution for their payment system.

_[hubliinetwork](http://hubii.network/" rel="noopener" target="blank" title=")

4) The future

A. OmiseGO’s future

What will happen between Omise and OmiseGO?

Eventually, all transactions using the original off-blockchain Omise solution will move to the OmiseGO blockchain.

What is OmiseGO’s roadmap?

As explained all above, OmiseGO is not a single application or service but a whole project, that the team has divided into 3 layers, which will be developped through time from the most crucial one to the most sophisticated one. OmiseGO has started publishing blog posts describing their roadmap according to terms of the game of Go.

• Layer 1: Omise Payment Acceptance Layer.

The Omise network is already accepting payments.

The next step to complete the Payment Acceptance Layer, is the release of the white label wallet SDK.

The SDK’s prototype will be released for testing in Q4 2017, and the public release is planned for Q1 2018.

- Layer 2: OmiseGO Decentralized Exchange (DEX) Network

The public blockchain release, including the DEX engine and allowing staking through the Proof of Stake system, is planned for Q2 2018. Until then, and until the release of Plasma, an intermediate scalability environment will be set, limited to the Omise network (not the whole public OmiseGO), using the Cosmos Network. This will introduce OMG stakers to the PoS protocol and already allow them to validate transactions. This should happen in Q4 2017,

- Layer 3: Decentralized Cash-in / cash-out touch point

This layer will allow users to digitize physical cash into digital currency (cash-in), and to turn digital currencies into cash that they can withdraw (cash-out). The solution for this will be revealed end of 2017, and the release date has not yet been made public.

- Horizon: Massively scalable cross-chain compatible DEX and permissionless network allowing payments and transfers

The final state of the OmiseGO network will require the release of Plasma, of which the date has not been announced yet.

B. Why invest in OmiseGO

First, it must absolutely be emphasized again that the author of this review is in no way entitled to give any investment advice to anyone. Investments are always very risky, and investments in the crypto-world are even more risky. So just like in any other project, investing in OmiseGO is a risk, and if you decide to take this risk, you should never invest more than what you can afford to completely lose. And not any thing written in this review refutes this fact, that you should never forget if you are considering putting money into OMG or into any other project.

Investment is risk / Donald Duck by Don Rosa, Credit Disney

This said, the investor’s business model is to rely on the idea that the OmiseGO network will handle a very high number of transactions, that these transactions will generate a very high amount of fees, and that, these fees being distributed to the OMG stakers, the more OMG you will hold and stake, the more amount you will receive per year, which, if the project keeps its promises, can turn into a very profitable passive income.

There are 2 main reasons to believe that the OmiseGO network will handle a very high number of transactions:

1 - The partnerships

The partnerships exposed below between OmiseGO and banks or private companies show that potentially millions of users or more can find themselves using financial applications running on the OmiseGO network, and generate an enormous amount of fees (although each being very low) to be shared between OMG stakers.

_Game of Go / Source OmiseGO [blog](https://blog.omisego.network/omisego-roadmap-v-1-40bfca386e25" rel="noopener" target="blank" title=")

2 - The SDK

OmiseGO is providing a programming framework that any company or bank can use to create its own financial (or value-exchange other than financial value) application for its own market and its own users, and these applications created with the OmiseGO SDK will also run on the OmiseGO network, and also generate a high amount of fees. And again, the programming framework will not in any way force the companies using it to have any OmiseGO logo on their application, neither any graphic obligation of any kind. The SDK will only be a certain collection of programmatic functions, in order to: save time and blockchain development cost, by using the trusted OmiseGO blockchain, and by using the trusted OmiseGO Software Development Kit.

In other words, the OmiseGO SDK can be seen as a free and easy gateway to the blockchain technology and to its potential financial applications, making in return that any company or institution using it, virtually becomes a partner of OmiseGO: if the company C provides its users with a wallet and application developped with the OmiseGO Software Development Kit, and has a user base of 10 000 or 1 million people, as soon as they make transactions using the application provided by the company C, these 10 000 or 1 million people become users of the OmiseGO network.

And so, these 10 000 or 1 million people, multiplied by the number of companies, banks or services that will use the OmiseGO SDK, generate fees on the OmiseGO network, distributed between the OmiseGO investors, named stakers or coin holders.

_Source OmiseGO [blog](https://blog.omisego.network/omisego-roadmap-v-1-40bfca386e25" rel="noopener" target="blank" title=")

5) Frequently Asked Questions

What will be the network’s fees’ amount?

It has not be decided yet, except that CEO Jun said in a post that they should be high enough to represent a real incentive for stakers and consequently secure the network with a sufficient amount of nodes, and low enough to make it a real benefit for users and companies to use the OmiseGO network.

What will be the minimum amount of OMG coins required for staking?

This information has not been released yet.

Is OMG an ERC20 token?

Yes.

Will the OMG token be replaced by another token in the future?

No. Some other projects have replaced their original token by a second token at some point of their development, but OmiseGO won’t. The OMG you own now will be the OMG you own in the future, their will be no token change.

Where to store OMG tokens?

Any ERC20 compatible wallet suits. A popular solution is www.myetherwallet.com (beware to type the right URL cause SCAM mirror copies of the site exist), and the solution consensually considered the most secured is a hardware wallet such as Ledger or Trezor. Note that this article is not giving you any guarantee about the safety of your coins if you use these solutions, but only displaying some commonly used solutions for informational purpose.

Where to buy OMG?

You can buy OMG on exchanges. Not every exchanges accept residents of every country, so you should check what website you can use, and also check the website’s reputation on specialized forums. Currently you need to first purchase Bitcoin, Litecoin or Ether, and then exchange them for OMG. Popular exchanges to purchase OMG include Bittrex, Binance or Bitfinex. Popular exchange to purchase Bitcoin include Kraken or Coinbase. None of these mentions either is to be considered an advice in any way or recommendation of any kind. As always when doing whatever you want to do with your money and with your computer and personal information, be careful and do your own research. And remember to never ever give your wallet’s private keys to anyone or to any website without triple-checking that it is your usual wallet provider, such as myetherwallet.com for instance, and triple-checking the URL: add the safe URL once for all as a bookmark on your browser, and never click on a link from another site pretending to link you there, even if it seems regular. Remember that the crypto world is full with hacking attempts, and that they can succeed when people are not careful enough. Be happy but be careful.

Links:

Omise’s website: http://omise.co/
OmiseGO’s website: http://omg.omise.co/
Note: any other website pretending to be Omise or OmiseGO is a SCAM. Don’t visit it.

OmiseGO’s Twitter: http://twitter.com/omise_go
Jun’s Twitter: https://twitter.com/JUN_Omise
Jun’s Medium: https://medium.com/@jun_omise
Donnie Harinsut’s Twitter: https://twitter.com/ruxperience

Joseph Poon’s Twitter: https://twitter.com/jcp
Vitalik Buterin’s Twitter: https://twitter.com/VitalikButerin

OmiseGO on Reddit: https://www.reddit.com/r/omise_go/
OmiseGO on Slack: https://omisego.slack.com/

Plasma’s website: http://plasma.io/
Cosmos Network’s website: https://cosmos.network/