How to Read Community Call Highlights for Crypto Projects

A community call is a live video or audio meeting where a project's team talks with its members. Topics usually include product updates, governance proposals, funding, security work or upcoming launches. Some calls run on Discord stages, some on X Spaces, and others on YouTube live streams or Telegram voice chats.

Many projects number their calls, so a 'sixth community call' is the sixth meeting in that series. The number tells you about sequence, not about importance. A later call can cover a minor update, while an earlier one may have introduced a major change.

Calls are useful because they show how a team explains its plans and answers hard questions in real time. They are not a formal disclosure. Statements made on a call can be incomplete, can be revised later, and are rarely backed by a legal document unless the team publishes one afterwards.

Most calls follow a rough structure:

• A short opening that sets the agenda
• Team updates, often with slides or a shared document
• A question round, in text or on voice
• A closing with next steps and the date of the next call

Knowing this structure helps you skim a recording or written recap quickly and find the parts that carry weight, such as dated commitments and decisions.

Start with the project's own channels. Check the official X account, the announcements channel on its Discord, its pinned Telegram posts, its blog, and its governance forum if it has one. Projects often post the recording, slides and a written recap within a few days of a call.

Use the project name together with the call number and the year when you search. Be aware that public reporting may not return a recap for the exact call you want. When we searched for a crypto project's sixth community call, the results were unrelated local community meetings, so this guide does not summarise any specific call.

If you have only a title such as 'Community Call 6', do not assume which project it belongs to. Many projects use similar naming. Wait until you can tie the recap to a named project and token before you rely on it.

When you find a recap, note where it came from. A post on the project's verified account, a pinned message in its official server, or a recording on its own channel is a stronger source than a repost, a screenshot, or a thread from an account you cannot verify.

Scam accounts often copy a project's name, logo and call titles. Before you trust a recap, confirm the match on several points at once:

• The project name and token ticker are spelled exactly as on its verified accounts
• The date matches the project's own announcements
• The host or speakers hold roles the project has published, such as team members listed in its docs
• The link to the recording or recap comes from the official account, not from a reply or direct message

A single matching detail is not enough. Impostors can copy a title or a date, but they are less likely to match all of them and also control the official channel.

If a recap asks you to visit a site, connect a wallet or join a private chat to see 'the full highlights', treat that as a warning sign. Official recaps are normally published openly in the project's own channels and do not require a wallet connection to read.

Keep a short note of the project, call number, date and source you used. That makes it easier to compare later recaps and to spot changes in what the team has said.

Not every line in a recap deserves equal attention. These are usually the parts that matter most:

• Roadmap changes, especially any dates that have moved or been removed
• Governance items, including what is being voted on, the voting period and any quorum requirement
• Token supply, emissions, unlock schedules or fee changes
• Security matters, such as audits completed, audits planned, bug bounty changes or incidents
• Team, role or contractor changes that affect who makes decisions
• Partnerships, which should be checked separately before you treat them as confirmed

Less important items are often general encouragement, community shout-outs and broad statements about the future. These may shape the mood of a call but rarely change how a project works.

When you read a section, ask what the team would have to do to make the claim true and whether it could be checked later. A specific, dated and checkable commitment is more useful to a reader than a vague promise.

If the recap includes numbers, note whether they are fixed facts, such as a published contract parameter, or changing measures, such as a total value locked figure. Changing figures need to be checked against live sources on the day you use them.

A useful habit is to sort each claim into one of three groups:

• Confirmed: backed by an on-chain record, a finished governance vote, a published audit, or a signed document you can open
• Stated: something the team said on the call, which may not yet be written down or verified
• Planned: something described as coming, such as a feature 'soon' or an idea the team is 'exploring'

Words such as 'soon', 'we hope', 'we are looking at' and 'likely' signal that a claim is not confirmed. Treat them as intentions. Words such as 'approved', 'deployed', 'executed' and 'passed' usually refer to something that has happened, but still check the source.

Quote the team carefully in your notes. Paraphrases tend to drift, and a small change in wording can change the meaning. Record the exact line, the time in the recording if available, and the speaker.

Finally, look for a written follow-up. If the team said it would publish a document, check whether it did. A promised document that never appears is a meaningful signal about the reliability of the claim.

Once you have a list of claims, check the ones that matter against sources the project cannot edit:

• Block explorers show contract addresses, token transfers and whether a function was called
• Governance interfaces and forums show proposals, voting results and the final outcome
• Official documentation shows parameters such as fees, collateral rules and interest models
• Published audit reports from named firms show scope, findings and whether issues were fixed

Figures that move often, such as total value locked, yields, prices and trading volume, should not be copied from a call. Check them on a live dashboard on the day you need them, and note the time you checked. A figure quoted on a call may have been accurate at the time it was spoken and wrong now.

For example, if a call mentions a change to how Lido's staking token holders vote, check the proposal in the governance forum and its on-chain vote. If a call mentions a Curve parameter change, check the CRV governance record instead of relying on the summary.

If you cannot find an on-chain or written source for a claim, mark it as unverified in your notes. That is a valid result and often the most honest one.

Community calls are a common target for scams, because they invite people to ask questions and join in. Practical defences include:

• Never share a seed phrase or private key. No legitimate team member needs them to host a call, verify a role or send a reward
• Type official web addresses yourself, or open them from the project's verified profile, rather than clicking links posted in a call chat
• Be wary of hosts who ask you to connect a wallet to 'verify' your membership or claim an allocation
• Watch for urgency, such as deadlines that pressure you to act during the call
• Check that anyone offering help in direct messages holds a role the project has published
• Review and revoke old token approvals in your wallet if you have connected it to unfamiliar sites
• Use a hardware wallet for significant holdings, and enable two-factor authentication on your exchange and email accounts

Screen-sharing requests are another risk. Do not let anyone take control of your device or ask you to read out codes sent to you.

If you think you have been targeted, stop interacting with the account, warn others in the official community channel, and report the account to the platform. If you have shared credentials or signed a transaction, move funds to a new wallet you control and seek help from the relevant platforms as soon as possible.

After you have verified a call's highlights, decide what, if anything, to do with them. A simple process helps:

1. Write a short summary with the project name, call number, date and source
2. List any dated commitments and set reminders for them
3. For governance items, read the full proposal in the official forum, then vote only through the project's official governance interface
4. Compare the claims with the next call or the next written update to see whether promises were kept

Do not buy, sell or stake a token only because a call sounded positive. Consider your own goals, time horizon and tolerance for loss. Protocols such as Lido, Sky, Curve and Jupiter publish governance activity through their own channels, so these can be useful places to follow what token holders are deciding over time.

If a decision involves trading or lending, check your local laws and the rules that apply to you before you proceed. Highlights from a call are not financial advice, and no call can guarantee outcomes.

Over several calls, the most valuable pattern is usually consistency. Note whether the team delivers on dates, explains changes openly and publishes follow-ups. That record is a more reliable guide than any single call's tone.