DApps are distributed applications running on the web facilitating the transfer of funds, goods or services.   In broad terms a DApp is a Smart Contract but although they make use of Blockchains some aspects of DApp functionality may involve centralised server hosting or manual/automated intervention by the DApp source.  A pure Smart Contract should be running autonomously on the Blockchain without intervention from its creator.

Dappradar currently lists over 13,500 DApps.   Popular functions include NFT exchanges, gambling and games (with in-game trading).  Several platforms have been developed with the specialised environment BNB Chain.  The core code within this and many other Smart Contract developments is Solidity; a ‘curly brace’ language that would be relatively easy for a Java or C++ programmer to pick up.  Other languages will also be involved; notably to dress up the code with a smart front end to pull in the users.

For all but the simplest ‘Hello World’ program there is a big leap between getting a working build and having a secure, robust solution.  Even the big boys of the application world make mistakes and (at best) fix these with updates and patches.  Systems are in place for identifying potential security issues but it is generally up to the developer to make use of them.  The Solidity ecosystem includes solutions such as Ethint to analyse and fix security bugs.  Binance fund a bug bounty scheme that pays out for identifying flaws on its cryptocurrency exchange.  These solutions are much looser than the Apple developer system that limits what applications can do and will only allow release through iTunes if these rules are met.  This is at the price of the system forcing developers to pay fees to Apple as well as making some applications impossible.

The consequence of the Smart Contract development system is that code could be vulnerable either because it is poorly written or through routines deliberately coded to scam the user.  Ethereum documents an example (the re-entrancy attack of how seemingly robust code can be exploited by withdrawing funds that do not exist in the buyer’s wallet (randomly taking these from other wallets).  The financial results of errors such as these would be coin not going to the expected destination accounts or of the project losing funds as coin is lost within the Blockchain.

Code samples and templates abound on the web.  Cryptomarketpool displays the following helpful warning : ‘This code is for learning and entertainment purposes only. The code has not been audited and use at your own risk. Remember smart contracts are experimental and could contain bugs.’  Not only might such sample code be unreliable; hackers can analyse it at leisure, working to identify potential flaws.  Coding errors can be minimised by analysis and reviewing code before it is released.  Peer review either within the development team or from an external body will also help to identify issues. 

While these are helpful if not essential tools for the developer the end user is faced with potential security flaws in any Smart Contract. Risk to the end user can be minimised by preferring well-established organisations that have the funds to weather the consequences of fraud and coding errors and re-imburse those affected.