Many projects are being built, or intend to build, on both Polkadot and Kusama. However, many claim to do so but have either no such intention, they don't have the resources to pull it through, or they're outright trying to scam people by misusing the Polkadot and Kusama brands.
Telling legitimate projects from the "not so honest" ones isn't always an easy task. This guide is meant to help you find out how to do your research better when you come across a project that seems interesting. What it's not meant to do, is label any single project as legitimate or not, or make that decision for you.
Furthermore, a legitimate project doesn't necessarily mean it will also be a successful one, and this guide is not meant to be viewed as financial or investment advice.
The statement "Powered by Polkadot" on many projects' sites is often a cause of confusion. This usually means that the project is building, or intends to build, on the Polkadot ecosystem, using Substrate. But any project can claim that, so the existence of this statement on a project's site infers no information about the project's legitimacy, and it's certainly not a "seal of approval" by Web3 Foundation.
The same thing goes for projects that have the "Polka" prefix in their name. Many projects use that to associate themselves with the ecosystem, some legitimately and others only to piggyback on Polkadot's reputation.
New projects usually try to increase their credibility by associating themselves with well-known entities. The thinking is simple: "These entities that have a good reputation trust us, so if you trust them, by association, you should trust us too". Indeed, association with a trusted entity can be a strong indicator of the legitimacy of a project.
For example, if a project has received a Web3 Foundation Grant, this is an indication that the project is indeed building on the Polkadot ecosystem, and if they have delivered all of their milestones, then their code is most likely of reasonable quality.
And Web3 Foundation is not the only entity in the ecosystem that gives grants. There are other reputable teams in the ecosystem that have developed platforms or prospective parachains and give grants for projects to build on or expand their project. These are also indicators that a project is committed to building on the broader Polkadot ecosystem.
Or receiving funding from VCs that you trust and are known to be involved with other reputable Polkadot projects can also be a good indicator. Or participating in the Substrate Builders Program.
However, claiming such associations and having them is not always the same thing. You always need to verify any claims a project makes, and that's probably the most critical takeaway from this guide.
For example, if a project has the Web3 Foundation Grant badge on their site or claims to have received a grant, check to see if they have received one and that it hasn't been terminated. The complete list of projects that have successfully applied for a grant can be found here, where you can see what each project has delivered and if, perhaps, their grant has been terminated.
The same thing goes for VC funding or another grant, or any advertised association for that matter. Check on the corresponding sites to make sure such claims are valid.
Also, make sure you understand the scope of the association. Going back to the Web3 grants example, they have a precise scope. They are granted for specific deliverables, and the review team only checks the code and evaluates these deliverables of the particular project. So, having received a Web3 grant provides no information about the general practices of a team, the longevity of the project besides the scope of the grant, or other projects the team might be building, which is why the badge rules clearly state that it shouldn't be displayed on the team's landing page.
Similarly, if a project claims to have partnered with a reputable entity, verify its scope and if it is indeed a partnership by searching their site for projects they have partnered with, their press releases, or by contacting them directly. And if you see such claims about Web3 Foundation, you can be sure they're false because Web3 Foundation does not partner with, or endorse, ecosystem projects.
An open-source project promotes transparency, builds trust, and ensures the project team isn't doing something suspicious behind the scenes. Additionally, it makes it very easy to track the project's progress and see how active the team is in developing it.
That doesn't mean, though, that any closed source project isn't legitimate or the team behind it has something to hide. Many teams choose to keep their code private to protect their intellectual property. And several teams that do so have gotten a General Grant, under which members of the grants review team review their private code.
Another thing that an open-source project allows you to see is if they have copied any code from other open sources. This isn't necessarily bad, since no one re-invents the wheel, but copied code should attribute to the source. If it doesn't, this should raise some red flags because the project team tries to feign expertise by passing someone else's code as their own.
A forked repo is easy to spot since it points to the original repo, but partially copied code might not be as easy to find. A quick search can provide you with some ways and tools to look for plagiarism.
So, a project being closed source isn't necessarily a red flag, it just limits the ability to verify the project in that regard, but there are indirect ways as described below. However, a project being open source is undoubtedly a good, strong indicator of its legitimacy because shady or poor practices seldom stay hidden for long in open source code.
If a project team constantly updates their product, it is always a good indication that they are serious and passionate about building. Regularly releasing new features and upgrades, fixing bugs, updating their site and notifying the community of these changes are good earmarks of a legitimate project.
Additionally, active development usually also means good development to be used as an indirect indicator for a closed source project.
An open-source project, of course, provides the ability to monitor the development activity through its GitHub repo directly.
The existence of solid documentation should be considered mandatory for any project that wants to be taken seriously. A couple of years ago, this meant a whitepaper, but lately, we've seen a shift to other forms of documentation, like wiki pages describing the various aspects.
No matter the form of the documentation, it needs to exist, and the more detailed it is, the better. This is where the project is explained in detail, and the prospective investor and user can read how it works, its goals and how the team aims to attain them.
The documentation will give you an idea of the technical expertise of the team, too. If they analyse their technology and the technical aspects, they indicate that they know what they're doing. On the other hand, if they focus only on tokenomics or analyse their project only in broad, vague terms, perhaps that's an indication that they don't have a clear path to their goals.
If you're looking for an example of what good documentation looks like, look no further than our own wiki. Of course, you shouldn't expect to find such extensive documentation on newly launched projects. Our wiki, after all, covers a whole ecosystem and was populated over the course of years. And it's still updated all the time. But it's a good example of the emphasis a good project should give on documentating what it does and how.
Some teams display their team members prominently on their site, along with their social media profiles (usually LinkedIn) and GitHub accounts, for development team members. This gives prospective users and investors the ability to verify the team's credentials, track records and expertise.
But the keyword here is verify! Don't take what you see on the project's team at face value. Look them up and verify their track record. Do a Google search for the team members mentioned. If it comes up empty, or the only results are regarding the project, it's an indication that their team members are fake. Their photos on their site, if there are any, will also probably be stock photos, or in other words, also fake. These are usually easily recognisable, but here is a guide on how to do a reverse image search, if you want to be thorough.
In some other cases, some developers prefer to maintain their anonymity, using pseudonyms, or the team members aren't mentioned at all. This isn't necessarily a bad thing. Perhaps the team is a strong proponent of privacy, or they want their work to speak for itself. Still, you should try and find out who's behind the project and what they're doing. For developers, their Github activity might speak louder than being mentioned by name. Other team members might be heavily engaged in their community, providing guidance and answers, which is always a good sign.
But if the team are ghosts that don't show up anywhere and only engage with the community through proxies, that's a red flag right there, and you should be very sceptical.
Besides their community, projects that are serious about building on Polkadot usually engage with the broader Polkadot community. They are active in the various Polkadot and Kusama channels, and some of them are Polkadot Ambassadors, or generally prominent members of the ecosystem.
There are many ways for a project to build on Polkadot and Kusama. Perhaps the most direct one is to aim to become a parachain. Some of the most notable Polkadot projects are already parachains on Kusama or gearing up to become one, and most of them will shoot for a Polkadot parachain too when they become live.
Of course, getting a parachain slot on either of the two main networks is not guaranteed, and all projects will need to win an auction for a parachain slot.
Verifying which projects are currently parachains on Kusama can be quickly done by visiting the parachains page on polkadot.js.org/apps. In the parathreads page you can see which projects are gearing up to claim a parachain slot, the auctions page shows which projects are bidding for the next slot, and the crowdloan page which projects are gathering funds from their community to participate in auctions.
But not all projects that build a chain using Substrate aim to become a parachain. Some use it simply because of its infrastructure to build their customised chain, without any plans to connect to the Relay Chain. And other projects may aim to become a parachain only on Kusama or directly on Polkadot.
However, building a potential parachain is not the only way to build on Polkadot and expand its ecosystem. A project might aim to build a DeFi platform on a parachain, launch a stablecoin or other token on Statemint, build a decentralised exchange, or any other dApp that one might think of, without ever touching the Relay Chain. And that's the beauty of Polkadot!
But in all of those cases, their plans to build on Polkadot, whatever they may be, should be clearly stated on their site and in their documentation. Most importantly, though, you should look for an explanation of how they plan to achieve that integration. A roadmap that places the integration at some point in the future means close to nothing without clearly stating the steps to get there. And these should be evaluated in tandem with your research on the technical expertise of the team.
This is especially true for projects that are already running on another network, like on Ethereum or Binance Smart Chain, and have issued tokens there. Many projects do that either to raise funds and test their infrastructure or because they aim to build a "multi-chain" solution or both. But because those projects aren't currently built on Substrate, the existence of a clear and robust integration plan with Polkadot should be essential in your research to ensure that they will indeed build on Polkadot one day.
The items above are what you should look at first when evaluating a project and should carry most of the weight in your decision. The reason is that they are hard to fake or manipulate, provided, of course, that you are able to verify the information found. Hence we called them "hard" metrics.
But there are other things to look for that might point to a project's legitimacy but can be more easily manipulated, so they shouldn't affect your decision heavily. These are called "soft" metrics.
The quality of a project's site could sometimes provide insights into the legitimacy of a project. A poorly constructed site, with typos and grammatical errors, or poor styling, a site that's a template without any serious effort to improve or change it, a site that holds little information about the project, without links to their GitHub or other resources, and generally a site that doesn't feel professional, are indications that the team is not serious about this project.
But that doesn't mean that all well-designed sites are also solid projects. This is a soft metric, after all. Many projects that don't have any plans to build anything substantial still have excellent, or even beautiful-looking, sites. They put many resources into how they present themselves visually to mislead. So, an excellent site doesn't necessarily indicate a legitimate project, a poor site might indicate an illegitimate one, but the site quality alone usually isn't enough to reach a conclusion. None of these metrics are; you need to look into all of them to make an educated decision.
Having a vibrant community is a good indication of a legitimate project. A team that engages with their community gives updates, answers questions, holds AMAs, posts articles, is a team that's interested in keeping their community members engaged and informed.
At the same time, though, social media presence and engagement can be easily faked and manipulated. Creating a Telegram group or a Discord server and filling it with thousands of bots is very easy. Although any bot users need to be identified on Discord according to its terms, scammers don't care about terms and conditions.
A team that tweets five times a day or posts a Medium article every other day isn't necessarily building something substantial.
So, make sure that you verify that their social media presence and engagement is genuine. Join their channels, ask questions and see first-hand what the community and the admins look like. If you're seeing a lot of users posting very brief comments, like "Good project", "To the moon", "Thank you" etc, without really engaging, be very skeptical and watch more closely, as these are probably bots. Additionally, verify any information shared by the team on social media and check what other people are saying. But verify those comments too, whether they're positive or negative.
Close to social media presence is media presence; third-party articles, mentions in YouTube videos and general promotions of the project.
When it comes to articles, the first thing to check is if the article is genuine coverage or a paid press release, especially when a project puts this coverage prominently on their page. Or if the author has any vested interest in promoting the project. You can check their previous articles to see if they systematically "shill" this project or projects in general.
The same thing, if not even more, goes for YouTubers and influencers in general. Many of them do this for a living or as a way to "pump" projects they have invested in. Finding good influencers that provide as objective info as possible usually involves its own separate research.
That's not to say that media exposure is terrible. It is probably the most abundant source of information outside the project itself, but at the same time, it requires extensive cross-checking and verification of information.
Nowadays, many projects use Telegram, Discord, or similar apps for community engagement, as well as the sole channel for communication and support. But having an email registered with their domain, besides providing another channel of communication, can be considered an additional credibility criterion.
Furthermore, receiving emails from the project's domain makes it easy to verify that the communication is authentic (but look out for spoofed emails!). On the other hand, communicating through personal emails or using a public email provider, like Google or Yahoo, might point to a not-too serious team or one that's spread too thin and could only be overlooked if the project is in its very early stages.
With the recent launch of parachains on Kusama, many projects that aim to become a parachain launched a crowdloan to gather the necessary funds to participate in the parachain auctions. But with all the buzz around the Kusama parachain launch and the imminent Polkadot launch, many scams may also surface. So, crowdloans need their own section to make sure that you're participating safely.
First of all, only projects that aim to become a parachain should have a crowdloan. If a project isn't a parachain candidate, there shouldn't be a crowdloan associated with it.
The surest way to participate in a parachain crowdloan is the native way through the Crowdloan module on Polkadot-JS Apps. This issues a special extrinsic that locks your funds until the parachain slot lease period ends and guarantees that you'll get your stake back after that. You can learn more about crowdloans through the link above and here.
Many parachain candidates offer a way to participate through their site as well. But you should ensure that they are using the crowdloan pallet in the background, and they're simply wrapping that in a nicer, more user-friendly UI. If instead, their crowdloan interface transfers funds to an account, these funds will be totally under their control, and this means you need to fully trust that the team will use the funds for the crowdloan, return your share to you when the lease period ends or if they don’t get a spot, and will secure them properly. If they're doing something like that, it should be explicitly mentioned in their site and documentation.
That being said, some teams have been doing token sales or swaps in an attempt to get a head start in raising funds for the auctions, but these are not crowdloans and still require full trust in the team. So, if you plan to participate in these token swaps, make sure the project is reputable and that you're getting the correct information through their official site and social media channels.
Similarly, several centralised exchanges are creating ways to participate in crowdloans through their platforms, while some wallets are integrating crowdloan functionality to their apps. And more are sure to follow. Any legitimate effort should be using the native crowdloans module in the background and offering a more streamlined user experience. Making sure that's the case is necessary before using these services, but in any case, it still involves trusting the exchange or the service provider.
Fact-checking is a skill necessary not only for DYOR but for filtering out the ton of information that we come across daily on the internet. If you're interested in learning more about how to check facts and verify claims, have a look at the following material.
- A very nice YouTube series on the art of fact-checking that covers a lot of ground can be found here.
- Another great resource on fact-checking, for those who prefer to read, can be found here.
- Wikipedia article on fact-checking
Finally, you should also check our complementary guide on how to identify scams. It's not about projects but how to identify outright scams and avoid them, as well as how to protect your sensitive information.
Once you've read all this material and have done your research and have identified a project as legitimate, one more thing you need to make sure of is that you understand what the project does and what new thing it aims to bring to the ecosystem.
This doesn't fall under fact-checking and verifying claims, but it's important to mention: fully understanding what something does and its prospecive impact is an integral part of making an informed decision, so don't overlook it.