Important factors to assess if one is to invest in digital assets and entities.

Intro

My name is Samuel JJ Gosling and I’m the Founder of a community-driven project known as Validity. Which aims to bring a wave of communal due diligence on the crypto-sphere, filtering out the bad projects from the good and vice versa. I’m here today to talk about a number of aspects that will help you form a viable conclusion to an investment decision, with the majority of the market composed of entirely speculative assets baring little utility that contributes to society, it’s important to question these entities.

Blockchain is far from a reality, I’ve seen all sides of the table, from being a clueless investor to a dedicated trader. To now finding myself as a developer, mind you this all progressed over the span of a year, which has been quite the journey indeed. I always argue that;

Money distorts logic.

Which is entirely true, if you go chasing the magic dragon in the hope to make a few ten thousand out of your hundred, you are probably going to lose it all. Why? You may ask, because you are so blind sighted at the temptation of making some revenue, that you forget what you are truly doing. This goes for investing in a project without the appropriate due diligence, attempting to arbitrage on an undisputed exchange, throwing down all of your stack onto a marginal with no stop limits and so on. Trust me, I’ve been there, I know.

So what’s the solution you may ask, it’s apparent that we are getting involved with investments to make some profit? Yes, that is correct but you have to evaluate what actually brings value and that its logic is correlated with its reasoning. Looking at a project and investing purely on the premise that the monetary value is cheap or it has a high supply, is an unwise move. Dig deeper, I’m not saying it’s a bad investment but its important to actually know what you are supporting and who is behind it.

Red Flags Overview

Use Case And Application

Social Media Presence

Plagiarism

Team

Code

Use Case And Application

To begin, let’s iterate over some questions that one should ask themselves if evaluating a said token, coin, exchange or dApp.

Does it need monetisation?

What problem does it solve?

Is there a working product or MVP (ICO /STO)?

Is there a variant form in standardised systems?

How effective is this implementation vs the standardised version?

Does it contribute to decentralised development/research or society?

Now I’m sure you’ve just had a moment of realisation that the majority of the assets existing on the market today have loopholes in their use cases. It’s a massive problem, one that a lot of people are overlooking. Let’s speak some of the most generic use cases within the space today, with a huge amount of projects aiming to be the “global currency” or the “cryptocurrency for everyone” to provide an easy and fun digital commodity, usually being a high ROI Proof of Stake clone, possibly topped with some master-nodes. If you want to wisely invest your revenue in the hope of some return, these opportunities may not yield a sufficient outcome. One has to be critical of their financial endorsements, especially in this space with all trust reliant on digital stances. Which can easily be un-credible and plagiaristic, it’s important to cross reference any mechanics or technological implementations.

When dealing with an unreputable exchange, it’s hard to factor the sanctity of such a project usually with most functioning a centralised exchange (CEX) and the other variants are decentralised exchanges (DEX). With the large majority of exchanges legally unregistered and anonymous due to tax implications. As a developer I strongly believe in DEX’s, due to the security benefits that puts control in the user’s hands. Unfortunately, there is not enough liquidity nor is the UX accommodating for adoption. Then there’s the CEX conundrum, where a significant quantity of volumes is wash-traded in the top 100 exchanges, but it doesn’t stop there. Leaving any assets on a CEX is a risky move and one could face the repercussions of frozen funds, “lost” funds or “hacked” funds. Let’s remind everyone of the infamous Coin Markets that disappeared overnight and ruined 100’s of projects, not to say that some survived triumphantly and are still active to this day. Sincerely if you ask me, it’s best to stick to DEX’s like for example Uniswap or some of top CEX exchanges bearing real volumes like Coinbase, Binance, Bitfinex and Bittrex.

Social Media Presence

This can be an important trait to alert one of an entity’s suspicious motives, being communicative with your consumers is important but it’s how one does this, that dictates the message.

Posts are orientated around price, market cap or volume speculation

ANN replies are completely generic via bots for social fabrication

Posts are promising profit or growth of your investment

Re-tweets a lot of unrelated content to its use-case

Pushing referral promotions during a crowd-sale

Social media accounts inactive for 3–6 months

A hugely significant amplifier of suspicion is any posts speculating on the financial support of the project’s asset. If you are wondering why this illustrates un-pure motives it’s because it creates an image that the entity/team has more of an inclination towards profit margins rather than their underlying product. The rationale of these variants of posts is fundamentally skewed to create somewhat of a market movement, which in all forms is classified as market manipulation. To be more judgemental of some social portals follow correlations between post likes and actual comments, when committing to social fabrication it’s usually by likes and very little comments. Real human users will usually reply but in a justifiable approach and not with some generic feedback that could be said about any project/post.

Plagiarism

A surprising but common aspect in the majority of cryptocurrency white-papers and is a clear implication that project has little knowledge towards what goal they are trying to achieve nor do they care, it showcases that the entity truly only cares about the financial benefits. If they didn’t they would have committed a sufficient amount of work to create authentic content that is exclusive to their product. That saying, given the power of money it does not stop some projects to continue to gain traction as most investors overlook external news. Two perfect examples of projects that have acted in this amoral method are Tron and DADI. Which is incredibly frightening to think one of these two is in the top 10 assets of the entire crypto market capitalisation, which goes to show how powerful market hype can be with the right marketing tactics. So as an investor how can you verify the authenticity of a project’s content? Below are some online portals where you can easily verify if plagiarism is imminent.

Team

Digital identities can easily be fabricated in the modern day era, credibility can be purchased via Linked-in connections, Twitter followers and not forgetting the un-pure pay-per-review ICO evaluation platforms. Over the past year, we’ve even seen some celebrities stock photos used for some fraudulent crowd-sales. Digital alterations are also utilised to change an existing identity to an imaginary alias or without their permission in a malicious act that harms one’s reputation. Ideal candidates should have the following traits to emit a pure identity.

Completely transparent identity and bears no anonymity

Has an active Linked-in and a correlating Twitter account

Developers must have a Git-Hub account or variant.

Some people argue that having somewhat of a partial anonymous team can still be viable and I agree given that none of the executive positions bears this trait. There have been situations in the past where projects have faced huge repercussions for allowing such arrangements as this. If one is to lead they must reveal who they truly are.

Let’s start with the entities stock photo or profile picture, a basic reverse-image search is a good ritual to have when verifying if an image has to be incorporated anywhere else on the web. Using a process such as this, one can be aware if an alias is being fabricated from associated pure identity, varying names for the exact visual appearance should be a clear indication. Make sure to download the highest resolution possible from any of the chosen identities social portals. Google, have a pretty good image engine that allows users to upload an image and get some similar matches but it only extends so far and isn’t entirely accurate at times. Below are some alternatives that may be of some benefit.

Next, we are going to verify the age of their social media accounts, by using one of my favourite tools the world wide web has to offer, the Internet Archive Wayback Machine!

Copy and paste the subject’s Linked-in, Twitter or Git-hub profile URL into the top search bar and see if there are any existing archives for the chosen team member. There should be at least one record when analysing up to three social media accounts if the identity has been in existence for more than 2–3 years. Be sure to verify by selecting a search that analyses all archives in correlation to that URL, as even a JSON response from an API can be credible. This may not be entirely accurate at times, as some URLs are not archived but it may provide a more intrinsic insight to the integrity of said identity if records are discovered.

Onto one of the most important factors when evaluating any developers for a chosen team, when analysing their Git-hub account make to pay close attention to their repositories and not their repository count. A real developer will only fork so much and if so, will have made adjustments to alter it’s a use-case or enhance the previous implementation. That being said if there are only forked repositories on the profile of the developer with exact similarities to the original source, this said “developer” isn’t what they claim to be nor do they have the track record apparent to illustrate their ability to create from scratch.

Code

Github has a great feature that allows repositories to be compared, given the huge amount of generic forking in the repositories that at times contain no changes to the original source exemplifies a poor execution on behalf of a project. Majority of cryptocurrencies are forked officially on Github but unfortunately, some aren’t either, there are methods to verify these unclaimed repositories but requires more commitment and analysing. For this instance, we shall keep it simple, let’s have a shot at analysing the differences between the original Bitcoin source code and it’s variant Litecoin.

If observed, the above analysis will show you file for file differences and commits to in relation to the master Bitcoin branch. Pay attention to the File Changed and Commits prefixes. If little to no changes are imminent it is clear that the fork is a generic clone and is no more efficient in relation to it’s predecessor. To compare a branch yourself use the following formula.

https://github.com/user/a-repo/compare/master...b-repo:master

For the previous comparison, the main parameters would equal the following

user = bitcoin

a-repo = bitcoin

b-repo = litecoin-project

So with a large sub-majority of cryptocurrencies being Solidity based tokens, it’s important to investigate given that it’s an easier process to be conducted if one wishes to create an asset. These digital commodities are usually built on standards like ERC20, ERC721 and soon to be ERC1400. What is important to verify when dealing with these assets that usually carry functionality of a monetised utility, is that there is no centralised control that could possibly skew investors participation in the long run. That saying majority of ERC20’s based tokens are nearly completely similar. Some projects incorporate a token just for the sake of monetising a dApp or allowing a financial stance to the project. So what do we need to be aware that may effect token holders in harmful aspects?

Centralised supply inflation with no supply cap

Centralised account balance alteration

Centralised account freezing

So how do differentiate where we can locate these aspects if they are imminent in the token contracts source. We use the nifty CTRL+F function to help us search for any matching keywords that may help us identify these potentially unethical implementations, our keywords will be the following

Keywords:

onlyOwner - function can only be called by the owner

_balances - token balance key-map storage

_totalSupply - token supply variable storage

_burn - function to decrease the supply

_mint - function to increase the supply

_mint - function to increase the supply

_frozen - account freeze key-map storage

_freeze - function to freeze accounts

Below are some amoral vs moral examples of the mentioned implementations

Inflatable Supply

// Not suitable function _mint(address _account, uint _value) internal {

require(_account != address(0x0));

// No condition present to limit the supply

_totalSupply = _totalSupply.add(_value);

_balances[_account] = _balances[_account].add(_value);

emit Transfer(address(0x0), _account, _value);

} function increaseSupply(address _account, uint _value) onlyOwner public {

_mint(_account, _value)

} // Suitable as where _maxSupply is defined elsewhere function _mint(address _account, uint256 _value) internal {

require(_account != address(0x0));

require(_totalSupply.add(_value) <= _maxSupply);

_totalSupply = _totalSupply.add(_value);

_balances[_account] = _balances[_account].add(_value);

emit Transfer(address(0x0), _account, _value);

} function increaseSupply(address _account, uint256 _value) onlyOwner public {

_mint(_account, _value)

}

Account Balance Alteration

// Not suitable function _burn(address _account, uint256 _value) internal {

require(_account != address(0));

_totalSupply = _totalSupply.sub(_value);

_balances[account] = _balances[_account].sub(_value);

emit Transfer(_account, address(0), _value);

} function changeBalance(address _account, uint256 _value) onlyOwner public {

_burn(_account, _value);

} // Suitable as the user is in control to burn their own tokens function _burn(address _account, uint256 _value) internal {

require(_account != address(0));

_totalSupply = _totalSupply.sub(_value);

_balances[account] = _balances[_account].sub(_value);

emit Transfer(_account, address(0), _value);

} function changeBalance(address _account, uint256 _value) public {

_burn(msg.sender, _value);

}

Account freezing

This implementation is not suitable in any situation as, why would one use a decentralised system for a centralised asset. One could accept this implementation if it resides on functions of delegation so that consensus could be reached to freeze an correlating account.

function _freeze(address _account) onlyOwner public {

require(_account != address(0x0));



_frozen[_account] = true;

emit Freeze(_account);

}

When evaluating dApps, it’s best to follow the flow of any transfer or transferFrom functions, as these could be malicious if you are not aware that a balance is requested from the caller and if not punted or use for a purchase is returned to the user.

So that about does it, as much as I’d like to progress with spreading advice to conduct viable due diligence, unfortunately, I can’t. However, if you did enjoy my approach make sure to check my founding project VLDY, that aims to create a distributed rating system for cryptocurrency assets and entities via crowdsourced evaluation. If you need a perspective on a project that has you unweary, do not hesitate to contact myself and I will be glad to help you form a feasible conclusion to obtain some clarity.

Thank you for taking the time to read this article.

References:

[1]: Wash-trading Statistics: https://www.blockchaintransparency.org/

[2]: CoinMarkets Exit: https://www.reddit.com/r/CryptoCurrency/comments/86ossq/coinsmarketscom_exit_scam/