--- title: How to Do Your Own Research (DYOR) description: Learn how to evaluate projects in the Polkadot ecosystem and distinguish legitimate ones from scams. url: https://developer.polkadot.com/wiki/general/how-to-dyor/ word_count: 3112 token_estimate: 3789 version_hash: sha256:05e7457cccbcbd38ae063bd7d665c6329bd67ad5fc1ff90f914d047217495d24 last_updated: 2026-11-01T15:55:43+00:00 --- 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 do not have the resources to pull it through, or they are outright trying to scam people by misusing the Polkadot and Kusama brands. Distinguishing legitimate projects from the dishonest ones is not 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 does not necessarily mean it will also be successful, and **this guide is not meant to be viewed as financial or investment advice.** !!! tip "Community project directories" To check whether a project is really part of the ecosystem, community-curated directories such as [Parachains.info](https://parachains.info/) list many teams building on Polkadot and Kusama and can be a useful starting point. Their accuracy and objectivity **cannot** be guaranteed, so treat them as one input to your own research — not a seal of approval. ## _Powered by Polkadot_ or _Polka_ prefix clarification 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](../../reference/parachains/index.md#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. This also applies for projects with a "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. ## _Hard_ metrics to look for when you DYOR ### Association with Entities You Trust 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 had received a [Web3 Foundation Grant](https://grants.web3.foundation), 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. Furthermore, Web3 Foundation is not the only entity in the ecosystem that provides grants. Other reputable teams in the ecosystem that have developed platforms or prospective parachains provide 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. Receiving funding from reputable VCs and are known to be involved with other reputable Polkadot projects can also be a good indicator. **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 is probably the most critical takeaway from this guide. For example, if a project has the [Web3 Foundation Grant badge](https://grants.web3.foundation/docs/Support%20Docs/grant-badge-guidelines) on their site or claims to have received a grant, check to see if they have received one and that it has not been terminated. The complete list of projects that have successfully applied for a grant can be found [here](https://grants.web3.foundation/applications), 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 should not 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. ### Open Source An open-source project promotes transparency, builds trust, and potentially ensures project team honesty. Additionally, it makes it very easy to track the project's progress and see how active the team is in developing it. However, that does not mean that any closed source project is not 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](https://github.com/w3f/General-Grants-Program), 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 wants to 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](https://duckduckgo.com/?q=search+for+copied+source+code+plagiarism&t=ffab&ia=web) can provide you with some ways and tools to look for plagiarism. So, a project being closed source is not 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 potentially strong indicator of its legitimacy because shady or poor practices seldom stay hidden for long in open source code. ### Active Development 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 allows anyone to monitor the development activity through its code repository directly, such as through GitHub. ### Comprehensive Documentation The existence of comprehensive documentation should be considered mandatory for any serious project. A couple of years ago, this meant a whitepaper, but lately, we have seen a shift to other forms of documentation, like wiki pages describing the various aspects. No matter the form of the documentation, its existence and completion is necessary, and the more detailed it is, the better. This is where the details of the project or parts of the project are explained in full for prospective investors or users. The documentation will also give you an idea of the technical expertise of the team. If the team analyses their technology and technical aspects, this is a potential indication of technical prowess. On the other hand, if the team focuses only on tokenomics or analyses their project only in broad, vague terms, this is potentially an indication that there is not a clear path to their goals. If you are looking for an example of good documentation, look no further than our own wiki. Of course, you should not 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 multiple years. Updates are also constantly being pushed out and edits are consistently being made. Nevertheless, this wiki provides a good example of the documentation a legitimate project should provide. ### Reputable Team Some teams display their team members prominently on their site, along with their social media profiles (usually LinkedIn) and GitHub accounts. This gives prospective users and investors the ability to verify the team's credentials, track records, and expertise. But the keyword here is **verify**! Do not 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 you are researching, it is an indication that their team members are potentially fake. Their photos on their site, if there are any, may also be stock photos, or in other words, also fake. These are usually easily recognisable, but here is a [guide](https://helpdeskgeek.com/how-to/free-reverse-image-search-tools/) 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 are not mentioned at all. This is not 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 is behind the project and what they are doing. For developers, their GitHub activity may be a stronger indicator of honesty. 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 do not show up anywhere and only engage with the community through proxies, this can be considered a red flag and extra precaution should be taken. Besides their community, projects that are serious about building on Polkadot usually engage with the [community](community.md). They are active in the various [Polkadot and Kusama channels](./community.md), and some of them are Polkadot Ambassadors, or generally prominent members of the ecosystem. ### Clear Integration There are many ways for a project to build on Polkadot. Some of the most notable Polkadot projects are parachains on Kusama or gearing up to become one. Parachains can purchase [coretime](../learn/learn-agile-coretime.md) and access a relay chain's core. Verifying which projects are parachains on Kusama can be quickly done by visiting the [parachains](https://polkadot.js.org/apps/#/parachains) page on [polkadot.js.org/apps](https://polkadot.js.org/apps). But not all projects that build a chain using [Substrate](../../reference/parachains/index.md#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 the Asset Hub, build a decentralized exchange, or any other dApp that one might think of, without ever touching the relay chain. 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, 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. These plans 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 are not built on Substrate, the existence of a clear and robust integration plan with the relay chain should be essential in your research to ensure that they will indeed build on it one day. ## _Soft_ metrics 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, assuming 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 should not affect your decision heavily. These are called "soft" metrics. ### Site Quality The quality of a project's site could sometimes provide insights into the legitimacy of a project. A poorly constructed site, may: - have typos, grammatical errors, or poor styling - be a template without any serious effort to improve or change it - hold little information about the project, without links to their GitHub or other resources - not "feel" professional These are all potential indications that the team is not serious about this project. But that does not mean that all well-designed sites are also solid projects. This is a soft metric, after all. Many projects that do not 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 does not necessarily indicate a legitimate project, a poor site might indicate an illegitimate one, but the site quality alone usually is not enough to reach a conclusion. None of these metrics are sufficient alone; you need to look into all of them to make an educated decision. ### Social Media Presence 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, and posts articles, is a team that is interested in keeping their community members updated and informed. Though at the same time, 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 bot users need to be identified on Discord according to its terms, scammers have little regard for terms and conditions. A team that tweets five times a day or posts a Medium article every other day may not necessarily be the 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 are seeing a lot of users posting very brief comments, like "Good project", "To the moon", "Thank you" etc, without really engaging, remain skeptical and maintain a critical eye, as these are probably bots. Additionally, verify any information shared by the team on social media and also verify the comments of users. ### Media Presence Related 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 displays 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 other projects in general. This especially applies for YouTubers and influencers in general, who may be dishonest. 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 is 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. ### Email Communication Nowadays, many projects use Telegram, Discord, or similar apps for community engagement, as well as the sole channel for communication, updates, 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 indicate a less serious team or one that is spread too thin. ### Additional Material Fact-checking is a skill necessary not only for DYOR but also for filtering out the plethora of information that we come across on the internet on a daily basis. If you are interested in learning more about fact-checking and claim verification, have a look at the following material. 1. A very nice YouTube series on the art of fact-checking that covers a lot of ground can be found [here](https://www.youtube.com/watch?v=L4aNmdL3Hr0&list=PL8dPuuaLjXtN07XYqqWSKpPrtNDiCHTzU). 2. Another great resource on fact-checking, for those who prefer to read, can be found [here](https://webliteracy.pressbooks.com). 3. Wikipedia article on [fact-checking](https://en.wikipedia.org/wiki/Fact-checking) Finally, you should also check our complementary guide on [how to identify scams](./scams.md), which explains how to identify outright scams and avoid them, as well as how to protect your sensitive information. ### One Last Piece of Advice Once you have read through this material and have done your research and have identified a project as legitimate, it is also imperative that you understand what the project does and what novelty it aims to bring to the ecosystem. This does not fall under fact-checking and verifying claims, but it is important to mention: fully understanding what something does and its prospective impact is an integral part of making an informed decision, so do not overlook it.