Money is one of the oldest technologies out there but yet only few of us truly understand how it actually works. In today’s world, money has become so complex that in most capitalistic societies, the rich have access to better ways of making more money and this create a huge wealth gap between the rich and the poor.

Which is why as of recent, concepts such as Universal Basic Income (UBI) have started gaining popularity as a way of bridging this wealth-gap (aside from also bringing people out of poverty and living less stressful lives)

In this post, I document my initial thoughts and experiments with UBI and on creating a fair money ecosystem using cryptocurrencies which:

• Does not widen the gap between the rich and poor and
• Is fully decentralised and self-sustainable.
• Is smart-enough for us to develop contracts or write code on top of it.

The problems with Bitcoin and Blockchain today

One of my main issues with Bitcoin is the fact that it’s wealth is far too centralised. Over 95% of all Bitcoins in circulation is held by only 4% of all registered wallets. This distribution is in fact, worse than the wealth gap in South Africa which is regarded as the world’s most unequal country.

While Bitcoin is doing a great job of taking power away from the banks/governments and redistributing it back to the people, it’s centralisation of wealth is a big problem when it comes to being an asset that can say, compete with Gold.

It is very often seen on many crypto-exchanges that there’s a lot of market manipulation that happens with Bitcoin by large traders who can easily move the market with a few million dollars. Compare this to Gold, where such trades are a drop in the ocean.

Aside from that, most public blockchains out there today are quite slow. If you were to buy a cup of coffee using Bitcoin, it’d take you about 30 minutes for you to verify that your transaction has gone through. We won’t discuss about scalability in this post, because there’s a lot of active research happening to solve those issues.

Using blockchain/cryptocurrencies to implement a UBI-based system is nothing new. With the decentralisation of Blockchain and with the programmability of cryptocurrencies, one could easily create a UBI-based cryptocurrency. (see this BitcoinTalk thread for a list of such currencies). However they face major issues, each of which I list below (and provide solutions to some).

Preventing Sybil Attacks

This is by far the most important problem of creating a UBI-based cryptocurrency. How to prevent the network from being attacked by a large number of fake nodes (or Sybil nodes) from claiming multiple UBIs from fake accounts.

Generally, to prevent a Sybil attack, we need to make it simply extremely hard and expensive for an attacker to perform such an attack.

A few UBI-based cryptocurrency (like CirclesUBI or UBIC) have attempted to solve this issue by either:

• asking for KYC-documents from users to identify themselves or
• by having have a trusted network of “validators” who are people who’ll allow new participants in a network.

However, these networks mostly face the issue that they are either too centralised or take user-identifiable information (like your Passport #, Government ID etc.) which become publicly exposed on the blockchain.

To prevent a Sybil attack, a completely different solution needs to be made which does not take user-identifiable information to confirm the identity of a user, nor should it have any network of “validators” but at the same time be able to identify real “humans”.

BrightID (whitepaper) by Adam Stallard and team seems to provide the right idea. It works by creating a decentralised network of users who cross-verify and rate themselves by forming real human groups. The more “human” the groups are, the higher the score they’ll get.

So individuals with a high score can be considered as genuine “humans” and would be eligible to receive a UBI.

Moreover imposing an account creation fee which is set to a considerable about (like 5–20$ per wallet) should make it considerably expensive for an attacker to create a large number of fake accounts.

This in combinations with restrictions defined to receive a UBI (defined below), should make it very hard for a dedicated attacker to try and game the network. I hope to find more ways to figure out how to make it also expensive to attack the network (maybe figure out a way to penalise bad actors?).

Conditions to receive a UBI

To make our system of Universal Basic Income sustainable, we should also define a few basic conditions for a person to make himself available to receive a UBI.

An income which is given to every user irrespective of how much effort they put in to contribute to the growth of the society is like giving away free money without any commitments. This sort of activity would most definitely reduce the value of the society. So the goal is to find how much effort a user should put in his society to justify receiving a UBI such that it’s:

• Not too much such that value of the work is valued more than the amount being given out as UBI.
• Not too less such that the UBI being given out is not devaluing the entire network as a whole.

I’d like to propose that every user who has an active account, which

• Has and maintains a high BrightID score
• Has made at least one transaction within the last 30 days

is eligible for a UBI.

Moreover if the UBI that is received is not spent within the next 90 days, then it should be refunded back to the network.

This allows us to give a UBI to only those users who are actually interacting within the system and also allows us to give the UBI to only those people who really need it.

Imposing a global wealth tax on users of the network

To even out the wealth gap that exists in Bitcoin and other fiat currencies, I’d like to propose a global wealth tax that will be imposed on the all users participating in the network.

This means (for example) at the end of every year, all wallets will pay a 1% tax to the network.

The money collected from this tax would then be redistributed back to all the users as their Universal Basic Income.

Since the wealth tax is a fixed percentage and the UBI for every person is a fixed amount, what happens is eventually as time goes by, wealth will get transferred slowly from the rich to the poor.

However, a wealth tax is not something the top wallet holders will appreciate and I have yet to figure if this will work or if we can find a proper incentive for them to pay the tax.

Having a cryptocurrency with UBI is not enough. Adoption is needed for it to survive

UBI is a concept that would work well within a society transacting in fiat currency like the US Dollar.

The reason is that the fiat currency itself has a lot of purchasing power. Which is why giving away a UBI paid out in a cryptocurrency that has no value at all would make no sense at all. There needs to be something that a person can do with the cryptocurrency for it to have some value for the person to consider.

Bitcoin found it’s early value in the online black markets (silk road) and eventually that helped drive it’s value up over time.

As of writing, I don’t know what would appeal a merchant to accept a new cryptocurrency (which promises UBI) when they can already use Bitcoin/Ethereum. Which means a UBI-based cryptocurrency will face major issues with adoption unless there’s something else unique about it.

Conclusion

UBI is a concept that at its core is attacking our greed for money which at many times can do more harm than good. Creating a system that supports a UBI is not going to be easy for any government to implement and it will face a lot of resistance from those in the top 1%. Which is why I believe going the decentralised route (with the use of a blockchain) is the only way forward.

While I figure out and explore more about what it takes to create a cryptocurrency with the promise of a Universal Basic Income, I’d like to encourage readers to share their thoughts with me and help me build this with your help, together. Once all parts of the story are made clear, I hope to complete a prototype of blockchain that supports a cryptocurrency that provides a UBI

Redesigning Money, using CryptoCurrencies to provide a Universal Basic Income was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Commitment Hashes are nothing more than cryptographic IoUs on the Ethereum blockchain. If you still haven’t got the idea, then continue reading.

In this post, I describe a very simple implementation of commitment hashes on the Ethereum blockchain. A Commitment hash is a special hash very similar to how commitment transactions work in the Lightning Network Whitepaper. If you haven’t read it yet, I would highly recommend going through it once.

Commitment hashes are a great way for creating blockchain applications that are simple and easy to use. Commitment hashes don’t need to be broadcast onto the blockchain but the very possession of them ensure that the user can claim something in the future. It’s like an IoU that is given to users.

But before we deep into the what/why of commitment hashes, I first will explain the problem for which I was trying to solve this for.

ENA coins and using the blockchain for music

On June 2018, I had met with Ena Marley, a wonderful and incredibly talented spanish musician who wanted to use her ideas on creating music that’d leave a deep social impact.

After a few weeks of discussion, we decided to launch a project that would create a cryptocurrency that will be used to represent shares in an artist (in this case called as ENA coins). Users/fans of the artist, would use the cryptocurrency to interact with the artist and earn royalties from the artist’s success.

However, the challenge with cryptocurrencies and making it easier for the public to use it

It’s pretty clear that 99.99% of Ena’s fans won’t even know what Ethereum is, let alone have even heard of Bitcoin. Which is a problem because it can really become hard for people to understand how to use the platform.

Since most users won’t have any Ether amongst themselves, the only way for people to interact with ENA coins was if somehow they were to interact with the blockchain and not pay any transaction fees at all.

Which means probably the site would have to pay for the transaction fees on behalf of the user if it needs to make any transaction. This clearly becomes very expensive as the number of users grows.

Using commitment hashes

Commitment hashes are very easy to generate. They are basically signed hashes (in our case, these hashes are signed by our server) that’ll allow the giver to cryptographically commit something (ENA coins) to the receiver (a registered user on the site).

These commitment hashes do not necessarily have to be transmitted onto the blockchain. However the very possession of the hash assures the receiver that he/she can use it to get what he/she wants; and the very creation and deliver of it, ensures the giver that he/she will have fulfilled his/her commitment.

Just like how paper money was used in the 1600s as an IoU for gold, commitment hashes are created to represent IoUs for some action on the blockchain.

The receiver can then send this hash to a public function in a smart-contract which is designed to behave in a specific way if and only if the hash was signed by the giver.

Use case of commitment hashes with ENA coins

In the case of ENA coins, non-crypto users will have an ethereum wallet generated for them from their web browser itself. This wallet will have no ether to pay for gas but it’s address will be used to hold ENA coins.

Generating a commitment hash

To generate a commitment hash, we use the code below which runs on the server-side.

This hash is what we call a “commitment hash”. The user can now use this hash at any time to claim his/her ENA coins from the ethereum blockchain.

Claiming the IoUs/Commitment hashes

Once the signed hash is created, it can be sent to the smart-contract at any time by the user. Here’s some sample code demonstrating a call made to metamask.

The smart-contract works by first recreating the hash from the input parameters sent to it. Once the hash is valid, the smart contract then verifies that it has been signed by the server. Once that’s done, it then finally mints the new ENA coins to the user and the commitment hash is marked as used.

There’s a nonce in place to prevent anybody from claiming a commitment hash twice.

The end result?

By simply holding a commitment hashes for say 1000 ENA coins, it is as good as saying that the user actually holds 1000 ENA coins because he/she knows that they can later use it to claim coins on the blockchain.

The website maintains an ethereum full-node, which keeps track of all the commitment hashes that have been claimed and use that to derive the final balance of all ENA coin holders.

Conclusions

With commitment hashes, our website can generate thousands of ENA coin accounts and credit users with coins to incentivise them for certain activities from within the site.

The ethereum blockchain is used for settlement whenever the user wants to take coins into her own hands for which she will need to find ether to pay for gas from somewhere. But for most use cases, the user never needs to know about the Ethereum blockchain at all.

Why use the term commitment hashes?

A few people have come up to me and have said “There’s already a concept called as meta-transactions. Isn’t this exactly the same?”

First off, It’s my wish to confuse everybody by creating a new term altogether. Hence the term “commitment hashes”.

Secondly, Meta-transactions are not IoUs. Commitment hashes need not ever be committed onto the blockchain because the very possession of it assures the user that he’ll get what he’s promised.

Commitment hashes are more easy to use and they can be adapted to many other use-cases. I hope you can build interesting things with it.

Scaling Ethereum on-chain with Commitment Hashes and 0% transaction fees was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog post documents some initial thoughts about creating a physical reserve which isin’t controlled by a single entity.

The main reason why cryptocurrencies like Bitcoin are highly volatile is because it’s not backed by an asset that is less volatile (like Gold) and the market cap of Bitcoin (and other cryptocurrencies) is very small.

As time goes by and as the market cap of Bitcoin steadily increases, we should see the price stabilise as well.

What’s the big deal with reserves and crypto?

In the crypto world today, we have seen many different uses-cases of crypto-currencies that are backed by an underlying asset.

For example,

• USDT is backed by a reserve of US dollars that a company called Tether has. INRFalcon is backed by a reserve of Indian rupee that a company called ThroughBit uses.
• Gold-backed cryptocurrencies (like GoldMint.io or OneGram.org) create crypto-tokens on the basis of the gold reserves that they have.

In all these examples, we see centralised entities having centralised reserves of some underlying assets which is then used to distribute IOUs that is backed by that asset in the form of some token.

ie. When you hold 1 USDT, you’re basically holding an IOU that says that Tether will agree to pay you 1 USD whenever you wish you return the IOU. This way, 1 USDT is always fixed to the value of 1 USD. (Unless of course, Tether begins to print/destroy more/less USDT than what they have in their reserves).

This highlights a few problems with centralised reserves

If for any reason, the company decides to shutdown and freeze all it’s reserves, then the IOUs that people hold become practically worthless.

And in some cases when a reserve grows in scale, it’s hard to audit them and actually verify if they hold that much assets as they claim they do. We always have to believe that they’re right about how much assets they have without any way of verifying if that’s actually true.

The solution? Decentralised reserves

A Decentralised reserve would bring in transparency in how assets that the reserve holds and ensures that the chances of a single entity influencing it will be very small.

We’ve already seen decentralised reserves, but that exists today in the digital form ie Bitcoin and other crypto-currencies.

What did we learn from Bitcoin?

Bitcoin taught us a very valuable lesson. That you could create a network protocol that’d allow you to create and use an asset that when distributed would require at least 51% of the participants to participate for any effective collusion to happen.

The question is, can we do the same for physical assets as well?

Creating a decentralised reserve that holds physical assets is much harder to do because humans just can’t be trusted. In the case of Bitcoin, consensus was achieved mathematically using digital signatures and all of this is digital.

However when we bring things in context of the physical world, a lot of those consensus rules need not be followed. Distributing an asset physically is hard.

Use cases for a decentralised reserve

For the first time we’ll get to have transparency in such a reserve, which will allow anybody at any point in time to see exactly how much assets the reserve has.

But at the same time, one of the most interesting use-cases would be in creating a cryptocurrencies that are pegged to a fiat currencies (using a decentralised reserve of the fiat currency).

Fiat money brings in a big limitation because of heavy stringent regulations and non-cooperation from the banks to deal with anything related to crypto-currencies (except for Ripple of course). This means that as of writing, in most countries, using fiat money to interact with crypto-currencies is very hard.

A decentralised reserve could actually help make cryptocurrencies and blockchain more mainstream because people will be presented with a cryptocurrency pegged to a fiat currency which they are more familiar with.

Making of a decentralised physical reserve — Note 1 was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve spent months researching on interoperable blockchains trying to figure out how to create one. In this post I have combined all my insights in hope to shed some further light on the topic.

Interoperable blockchains are the future: A brief

Interoperable blockchains basically allows users to interact with multiple of different types to communicate with each other.

Take atomic swaps for example. Atomic swaps allow for two blockchains to “speak” to each-other and allow for two parties to securely trade cryptocurrencies between the two blockchains (for example between Bitcoin & Litecoin).

But atomic swaps are just the start

Many new projects have come up that have promised to offer more than just atomic swaps. These projects promise to create a blockchain that can actually speak and interact with blockchains and allow developers to extend the functionality of these chains.

A typical interaction with an interoperable blockchain would be one wherein you have a have a balance of multiple other cryptocurrencies (like Bitcoin) and you can create smart-contracts that’d interact with these cryptocurrencies (so for example, you can probably write a smart-contract that does something with Bitcoin! which you otherwise couldn’t do with the native Bitcoin blockchain)

Couple of projects in this space include

• Wanchain
• Blockstream’s liquid
• Polkadot
• Ethereum’s Plasma

Each whitepaper brings forward major breakthroughs and revolutionary concepts, full-filling the promise of creating a scalable interoperable blockchain.

These blockchain projects come with a big promise. That they’ll be able to create a system that will be able to speak to other blockchains and which will truly be decentralised.

But the question is, will they be successful? Will they be able to include blockchains like Bitcoin? I think not. And here’s why.

What’s happening under the hood behind these interoperable chains?

In Ethereum’s plasma, things are pretty straightforward. A side-chain following the plasma protocol will ask a user to deposit ether into a smart-contract controlled and monitored by the side-chain.

Once a deposit is made and locked in the Ethereum smart-contract, pegged tokens are immediately issued to the user on the side-chain and then used within the side-chain itself.

Whenever a user wants to withdraw ether from the side-chain, the pegged-tokens are burnt and the ether is released from the Ethereum smart-contract and sent back to the user.

Take Matic.network for example. A side-chain based on Ethereum’s plasma that allows users to interact with Ethereum in a proof-of-stake model.

With Ethereum, interoperability is pretty simple because of the fact that Ethereum supports smart-contracts and you can write very complex logic to support your ‘interoperable needs’.

But what about blockchains like Bitcoin or Tether? Blockchains that don’t support smart-contracts-like functionality? Is there a way to properly lock funds and interact with these chains?

Let’s look at Bitcoin and dig deeper. How will an interoperable chain work with Bitcoin?

What many papers have proposed is something similar to Ethereum’s plasma.

You place your Bitcoins in a wallet controlled by an interoperable chain and you’ll immediately get pegged tokens on the interoperable chain that’ll represent those Bitcoins.

But the question is this. How does one ensure that the Bitcoin wallet provided by interoperable chain is secure? The only way for you to have control over the funds from such a wallet was if you held the private key to sign transactions and spend from that wallet.

And this is the crux of the problem with interoperable blockchains. How can you prevent misuse of the private keys of a wallet controlled by the nodes in an interoperable blockchain?

After going through various solutions, I’ve summarised my findings and what different people are doing below.

1. Have few nodes manage the private keys

This is what Blockstream mentions in their whitepaper. https://blockstream.com/strong-federations.pdf

However the main issue with this is that it is very much centralised as one would have to trust Blockstream to not misuse these private keys.

2. Have many nodes keep pieces of the private key

In this case, the private key is split into ’n’ different pieces and distributed across ’n’ different participants.

At any point of time, whenever the private key needs to be recreated, the pieces are brought together and the entire key is reconstructed.

You can take this a step further by using a key-sharing algorithm like Shamir’s secret sharing algorithm and split the private key into ’n’ parts but only require ‘k’ parts (where k ≤ n) to reconstruct the entire private key.

However the problem here is that the once the private key is reconstructed, it can very well be misused by the node who has it. Which makes this system effective if only one transaction needs to be made as after that the security features of the wallet will be broken.

3. Have many nodes keep signature shares of the private key (n-of-n)

So this is similar to Shamir’s secret sharing algorithm however the private key is never reconstructed in the network.

If you have 20 nodes that keep 20 pieces of a private key, each node can sign the raw transaction using their own piece and create their own ‘signature shares’. Each ‘signature share’ can later on be used to create the final signed transaction.

The problem here however, is that this is a n-of-n solution, not k-of-n. Which means that even if one node drops out of the network, then there’s no way for the other nodes to gather all ‘signature shares’ required to create the final signed transaction. Hence effectively making the wallet inaccessible until the dropped node comes back online.

Some ideas to counter this could include penalising nodes that drop out. But again another question arises what is the penalty? Will the penalty be enough to recover the funds locked in the wallet?

4. Have many nodes keep signature shares of the private key (k-of-n)

This is what ideal case for interoperable blockchains should ideally.

There are implementations of k-of-n solutions where you can create a full signature using k signature shares from n shares, however these operations are not scalable as n increases and k decreases.

Researches from Princeton University have published an excellent paper where they’ve described a “threshold signature scheme”. They’ve even open-sourced an implementation of their algorithm in Android. However the main issue with their system is that as the number of participants increase, the time-complexity increases exponentially.

Which makes this system ineffective as you try to have more than 20 key shares.

Taking a few lessons from EOS

As of writing EOS is now exactly a month old. However to say it’s journey hasn’t been smooth is clearly an understatement.

The main issue right now is that EOS centralised? Is 21 block producers a good enough number for EOS to stay decentralised? What are the chances that block producers will not try to collude with each other?

What EOS & Bitcoin teaches us is that we should remove power away from humans and give it to the impartial machines.

However the question arrises that what if we did that fully how can we ensure.

Conclusion

To create a truly hybrid exchange, one needs to first solve the problems with interoperable blockchains first.

While we’re at the most interesting of times in the Blockchain era, I just don’t see how many of the ICOs/projects that claim to be creating an interoperable chain are actually able to create a fully decentralised system, without having tackled the issues with any of the four solutions above.

If you have suggestions or if you think I’ve missed out something, please feel free to let me know.

Problems with interoperable blockchains & hybrid exchanges was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is an archive from Jan 16, 2016. Link

I’m a huge fan of the Backtrack OS. I loved especially how it had used the console to login. Which is why when I switched to Kali, I had disabled the GUI login and re-enable the console login just to get that old feel.

But of course, just like in Backtrack, I would end up spending most of time in the GUI desktop than with TTYs. I must have probably entered “startx” more than a few thousand times now. It would make more sense for me to switch back to a GUI login, but I can’t because I love starting from TTYs. It makes you look a programmer who’s so hardcore even though you don’t know shit.

So I figured it might be a fun idea to make a snake game that would run where the login prompt would usually be, and have it start up my Desktop when the snake eats the fruit.

And so I did

I found a nice terminal snake game called nSnake, hacked it’s code a bit, messed around with a few startup scripts in my machine and Voila!

I now power on my machine, wait a second for it to boot up, play a game of snake and then watch it load my desktop along with my badass wallpaper of an ameoba.

Now, isin’t that way more insecure than a regular login prompt?

Yes, well not exactly. The snake game launches the GUI, which usually brings up your familiar login screen (where you would click on your username and enter your password).

However! you would want to bypass that and forget about your security just cause it’s too damn cool to watch your desktop launch from a terminal snake game.

Most login GUIs have a autologin feature which will automatically log you in and present your desktop. We shall use this feature.

Setting up the snake game

The game and it’s source code can be found here. Follow the instructions in the Readme file, as it contains step-by-step instuctions on what you should do to get the everything setup. Note that I have tested it only in a Linux system (OSX is still in question and Windows, well…. never mind).

Once done, reboot your system and you should see the changes to take effect.

Behind the gears

The snake game is modified so that it loads an external program (which we specify) when the snake eats the fruit. We set the external program to be our GUI interface, which means the snake game launches the GUI interface when it eats the fruit.

Then we disable the GUI from starting up automatically during boot, and instead have the snake game load up from boot. The snake game is loaded in TTY1, which is the default terminal that Linux switches to when there is no GUI taking over.

Does this work for multiple users?

Yes, if you did not disable the GUI’s autologin feature, but no otherwise.

Although, I wonder if someone can think of a way to create something where there will be different coloured fruits in the game so that each fruit would represent each user in the system. Having the snake eat a fruit that represnts a user, would cause it to load the desktop of that user. THAT, would be really fun in a multi-user system. (Of course keeping in mind, password prompts and the number of users).

Contribute

Finally, the most interesting part of this article to me.

Linked here again is the source code. It is open-sourced and I’m really excited to see some creative ideas come out of this.

Maybe have more security, or some more games, or even some freaky digital music play on the background. The creative possibilities are just endless!

Terminal Snake login was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is an archive from May 4, 2016.

This post just details my thoughts and plans for creating a mobile payment system for the poor in India. The photo above is from a hackathon which Barclays conducted in November 2015, which was the first time I got introduced to the world of mobile banking.

The Situation

Mobile payments are something that is very hot in India right now. In a country where most of the population falls in the unbanked and underbanked sector, it’s not a puzzle why banks would want to figure out ways to tap into this audience.

India has already seen the use of systems like m-Pesa (owned by Vodafone) and PayTm, which try their best to bring mobile money to everyone.

While PayTm is the biggest mobile wallet in India today, it is used by people who have access to a smartphone. On the other hand, while mPesa is the biggest USSD mobile wallet in countries like Kenya, it is not that widely used in India because of the inability to send money to numbers on other networks other than Vodafone (cross-network payment).

Why don’t mobile apps work?

Majority of Indians are still under the poverty line and hence it’s not possible for them to spend as much 1.5K Rs on a smartphone when their monthly household income comes to just 10k Rs. There is, however a wide use of brick phones, which are far more cheaper than smartphones. However, brick phones don’t have apps hence mobile solutions like PayTm cannot be used on these devices.

But for many households, getting a smartphone is a luxury. And while the prices for a smartphone are becoming cheaper and cheaper (See Freedom 251), you do have people who are happy with spending a little bit more because they treat a smartphone as a long-term investment.

Still, as India is slowly improving technologically; It will be a long while before we see smartphones everywhere.

Why current USSD services won’t work

If you’ve ever been to Kenya then you’ve definitely heard of mPesa. mPesa is payment system where you type in a USSD code (*400#) and press call and a simple menu comes about. The menu has a few options for you to check your m-Pesa balance and send money from one number to another.

It’s a simple and beautiful system which allows people to use mobile money with a brick phone. It’s fast, simple and widely used in Kenya.

What about India? Will USSD money work in India?

m-Pesa unfortunately, is not that widely used in India. It works in countries like Kenya because the company that runs m-Pesa, Safaricom is a monopoly in the Kenyan telecom space. m-Pesa had the first-mover advantage in Kenya.

In India (and in other countries), mobile providers soon became aware of this concept and have started replicating the system on their own.

Which is why now you have along with Vodafone’s “mPesa”, Airtel’s “Airtel Money”, Reliance’s “Reliance money” etc. all being offered to the consumer with the same features. mPesa (in fact, none of the mobile wallets) have been successful in going mainstream in India.

What’s wrong with USSD?

USSD is primarily restricted to the network carrier it is offered on. Which means that if you can type in *400# on your Vodafone SIM to access mPesa, you won’t be able to do the same if you had an Airtel SIM.

USSD is great since it is fast, simple and nearly all phones (including bricks) can run USSD codes. But the competition and the challenges that mobile networks providers face make it nearly impossible for USSD money to become mainstream in India.

Some ideas to tackle this

So I’ll note down some good ideas that have come about over, that basically attempt to solve the problem.

1. Using SMS for mobile money

There is however a third option (besides apps and USSD), which also has it’s pros and cons. A common service that is used by everyone, SMS (Short messaging service). If you haven’t realized, SMS and phone calls are some of the few services that can talk across different networks. That is, a person with an Airtel sim can send an SMS to a person with a Vodafone sim.

Which means that there might be some way for us to create a mobile system using SMS as a medium, right? It’s pretty easy to do so in fact. During Barclay’s hackathon (photo above), My team and I made a prototype that could transfer money from one number to another using one simple SMS command.

But SMS is really slow. SMS takes on average 5–10 seconds to send and receive. Which means a typical transaction could take well about 10–20 seconds (A SMS going to us and a confirmation back to the user). Also SMS in the end is tied down to the carrier.

2. Having a joint collaboration with the banks and telecom providers

You could have a collaboration to create an entity wherein every bank and telecom provider has a certain fair share and they all could work collaboratively. If that is even possible, then the telecom providers would all agree to integrate a common system and that then everyone could send/receive mobile money via USSD to anyone in India.

This won’t really happen, because no-one would be interested unless it is forced as a government initiative. Which is why NCPI was able to create a unified interface for anyone to send money from their bank accounts through a simple USSD interface. They call it the NCPI Unified USSD platform.

NCPI lets you transfer money from one bank account to another, by having you punch in your account number & IFSC code through the USSD menu (good luck remembering that).

The problem here is that NCPI forces the user to have a bank account. And while there are schemes like the Jan Dhan Yojana which has opened 200m+ bank accounts for the poor (a large portion of it, still being dormant); many people associate that a bank account is too expensive.

And typing in the bank account number makes it absolutely irritating when it comes to simple things like paying your milkman.

3. Use IVR and make it accessible via a toll-free number

With the help of IVR, we could still create an automated system and the fact that we could have a toll-free number would imply that anyone in the region could access it for free.

The only issue here is that having toll-free numbers are usually very expensive and again is maintained (hence restricted) by a network provider. However, if such a system is legally approved (by the RBI) then the network provider would have no rights to take down the system (because you could legally sue them and win).

4. Start your own telecom service

Being your own telecom provider would allow you to send SMSs at lightning fast speed (Because you are the SMS server). A typical transaction can go down to anywhere between 5–10 seconds (instead of 20–30). You could even run your own toll-free number.

But in India, to legally start your own telecom service, you would need to reserve a frequency band which unfortunately would cost you in the billions.

5. Have a decentralised system using SMS

Having a decentralised system allows it be completely independent of any outside influence and it will be very hard to be taken down. While SMS might be slow, it is probably the only thing that works.

Such a system would raise a lot of regulatory concerns and it also might end up being rejected by many people (especially merchants) if it turns out to be illegal.

I have yet to think of how such a system would work.

What I’m trying to do

I believe that creating a decentralised system is the best way to go for something like this. The main issue I haven’t solved (which is a very core one) is to figure out how the accounts for every number & transaction would be distributed. How can we create a system where there has a good ledgering mechanism (much like the blockchain), but at the same time being very simple for anyone to use?

There are a lot more challenges to this, but I’ll leave it for the reader to ponder over.

Creating a decentralised system would make the most sense as it cannot be controlled or taken down by any network provider. If thought about correctly, it would at least be something that would survive the obvious pressure from the banks, who would not like anything that dominates the market except for themselves.

Decentralised Mobile Payments for the poor was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kuwait and Me was a site I launched back in December 2014. Being in Kuwait for nearly 12 years I decided that’s it’s about time I did something back for the country and the first thing that came into my mind was creating a wonderful community where people could exchange stuff locally online.

Classifieds and my kitten

When I was in Canada, one of the things that was really popular there were classified sites like Craigslist or Kijiji.They were like local sites where people would sell their stuff locally and it was the first time I ever heard of it.

That’s a picture of Vanellope. A kitten I found from a classifieds site while I was living in my lonely apartment in Toronto. Having her will be one my most memorable experiences that I’ll ever have and giving her away will be one my biggest regrets.

But still, there was this “irreplaceable joy” that a pet would give someone, and I was so in love with mine that I wanted everyone in the world to get something like that.

I knew that Kuwait didn’t have an active classifieds website like the one in Toronto. Which was why I decided to create Kuwait & Me, with a mission to bring the same kinds of love and happiness to the people of Kuwait.

And so the website was created

I began making the website in December 2014, and got something up by the end of March. It wasn’t too complicated had a simple login & search functionality. It looked like any basic classified site.

This was a screenshot of the third version, which was not too different from the second. There were just small changes in the design (most of it inspired by pintrest) and more UX issues cleared out of the way.

But something was wrong.

After marketing on social networks and doing a ton of SEO, I was still running dry for a good 4–5 months. No signups/classifieds for weeks long and by the end of 6 months I got only a 100 classifieds and 25 users among 10,000 visits. I had a bounce rate of nearly 98% and no regulars.

I worked really hard on the site and I wondered “why aren’t people coming into the site?”. I thought that it was probably because my design was bad, or that my marketing wasn’t strong enough. But after speaking to a lot of entrepreneurs, I realized in reality it was actually something far worse.

Why I took it down?

Like most startups. I failed to correctly validate my idea and I spent so much time building the wrong product. I made something because its looked like a bright money-making idea and it excited me so much that I assumed it had to be a success.

But it turns out that, classifieds might not have been the right way to approach the problem; If someone had to experience that the joy of sharing, then the site would have to work in a much different way than a local marketplace. Ecomodo, Peerby are some interesting ideas (and I’ll leave this for the reader to explore). What a classifieds site bought instead where people who wanted to make money, which included real estate agents, local businesses and illegal dealers (black money & drugs). This was not what I wanted.

Apart from building the wrong product, I also underestimated my market and my competitors as well; My market was small and my biggest competitor was a company called dubizzle, which got recently acquired by Olx. Olx, (being the giant it is) stomped me the moment they entered the classified scene in Kuwait.

I spent months in developing the site and I could have kept everything running just the way it was, but it required a lot maintenance, time and money. And on the top of it all, I moved to an another country mid-way through developing the site. In other words, my situation is best summed up by this quote.

“If the ladder is not leaning against the right wall, every step we take just gets us to the wrong place faster.”

Stephen R. Covey

Perseverance is key, yes. But uneducated perseverance is worse than having any perseverance at all.

Creating this site is always going to be an amazing learning experience for me, and I’ll keep it just to that.

What I’ve learnt?

Although I’ve clearly gotten to know a lot about coding in Node.js and MongoDB, there are a few key values that I would like to mention.

• Unless you have the experience of doing a startup, being a solo-founder just will be too much to handle. I did everything my myself; Designing the logo, developing & maintaining the site, marketing on social networks & SEO etc.. There’s only little a human can do and I could clearly see how much the stress would have faded away if I had another co-founder by my side.
• You need to always validate your model, speak to your customers and analyze your competition. I thought that what I did was what people would want, and my assumptions had to later prove me wrong. I had validated the idea by my friends, family and with myself (and not with my real customers).
• Even if you don’t create the final product with all it’s amazing features and sparkly buttons; if you have at least something out there that works, then there’s always room for improvement. Over the period of 6 months, I’ve revised the design about 5 times, changed the entire framework twice and had to completely erase and restart the database thrice. If I had continued to improve with I had in the beginning then I could have reached much further ahead. Furthermore, if I had continued with whatever I had, it would still have been better than nothing.

Will I bring it up again?

No. It’s pretty much dead and it’ll take a lot energy (and capital) for me to resurrect it. I’ve left Kuwait and it’s been nearly a year now so it’ll be hard to do a startup while you’re in another country.

I have learnt a lot by doing the site but I don’t think it’s sustainable for me anymore. Right now I have a thousand other exciting things to do, so I’ll keep this aside for now. Until then, see you next time!

—

If you found the story interesting and you want to do something similar, you can find the code to the site here; Although most part of it has been left broken (and probably the ugliest code you’ll ever encounter).

How Kuwait & Me, a small startup that I built to spread the joy of giving in Kuwait, died was originally published in Steven Enamakel on Medium, where people are continuing the conversation by highlighting and responding to this story.