O

OmniEther

Continuing the propaganda to replace conventional money with cryptocurrencies in order to solve financial problems, we take a step forward at eradicating corruption from all sorts of organisations

O

OmniEther

Continuing the propaganda to replace conventional money with cryptocurrencies in order to solve financial problems, we take a step forward at eradicating corruption from all sorts of organisations

The problem OmniEther solves

Controlling Fraud and leakage of assets in terms of money or any other important data e.g. In 1985 Rajiv Gandhi said that for every 1 rupee allotted only 15 paisa reaches to benefactor. In a simple way anything which is owned by public should not be misused by any single person in any way. Reduces Corruption, reduces fraud like Nirav Modi, Vijay Malaya case. Like in these cases they are successfully able to transfer their Company money into their own private account for their own benefit.

Basically we intend to convert a hierarchy of financial distribution to a hierarchy of Ethereum smart contracts. Instead of trusting someone with money, we keep it the trustless way, in contracts, which shall govern its further flow. Moreover the parent managers in the hierarchy decide if the money is being truly sent to rightful hands or into corrupted people's pockets. When money needs to be transferred from a contract( leaf node in hierarchy) to an external organisation, we conduct bidding and provide the required money to the lowest bidder.

Moreover, in order to keep up with the spirit of Web 3.0 and decentralisation, we are using the famous P2P file system IPFS and OrbitDB, a database built upon IPFS, to store user credentials and chat logs, all symmetrically encrypted.

Challenges we ran into

Problem 1) Using OrbitDB to maintain decentralised databases. Since OrbitDB is purely alpha software( of course, given IPFS is too, atleast its JS implementation), its behaviour was maddening to us, people who are just getting exposed to P2P architectures. The database absolutely refused to replicate its data for different peers. We later found out that this was because our local databases were unable to connect to remote peer databases.

Solution) For this we had to create an always running bootstrap node which our IPFS nodes must positively connect to in order to replicate databases. We hosted this server in an AWS EC2 instance. Although this may introduce some amount of centralisation in our system, this is the only way available in this client-server dominated web of today. Moreover we had to add go-ipfs options in our js-ipfs "server" instance and add numerous generic bootstrap nodes in our web DApp as js-ipfs browser instances do not have DHT and can only listen to websockets. browser limitations :(

Discussion