How to Review a DeFi Support Notice
A cautious process for distinguishing maintenance, user action, network delay and account guidance.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A support notice is the one document a protocol publishes when something changes on chain. The trouble is that most notices look alike at first glance, and reading them in the wrong order is how people end up taking action they did not need to take.
This guide is about one specific task: reading a DeFi support notice and working out which of four things it is actually describing.
The four kinds of notice
Before anything else, decide which category the notice falls into. The four categories lead to four different responses, and confusing them is the expensive mistake.
Maintenance. Planned work on the protocol itself. Funds are usually safe, withdrawals or deposits may be paused, and no action is required from you. The tell is a stated start and end time, or a window measured in hours.
User action. Something about your own account, balance or position needs to change. This is the only category where you should be doing something. The tell is a direct reference to a position, a claim, a migration or a specific contract.
Network delay. The protocol is fine but the underlying chain is congested or the transaction is stuck. The tell is language about pending transactions, confirmations, gas prices or network conditions, with no mention of a protocol upgrade.
Account guidance. A communication about the support desk, identity checks, account recovery or a phishing warning. The tell is a request for documents or a link to a portal, with no on-chain specifics.
If you cannot place the notice in one of these four buckets, that is itself useful information. It usually means the notice is a general announcement rather than an operational instruction.
Read the notice in this order
Start with the domain. Support notices are the most common phishing vector in this entire industry, because the format is public and the timing is predictable. Check that you reached the notice by navigating from the protocol’s own application or its verified social account, not from a link in a direct message, a search advertisement or an email.
Confirm the publication date next. A notice from nine months ago may describe a situation that has already been resolved, and acting on a stale instruction is its own risk.
Then read what is actually affected. Name the network, the contract address, the asset and the action window. A notice that does not name a specific contract is describing a general condition rather than asking you to interact with something.
Read what you are being asked to do last, and separate it into two lists: things you do on a site you already trust, and things that require you to connect a wallet or sign a transaction. The second list deserves a much higher bar of suspicion than the first.
What to verify before you act
- The link came from the protocol’s application or its verified account, not from an unsolicited message.
- The publication date is recent enough that the described condition still applies.
- The contract addresses named in the notice match the addresses visible in your own wallet or the protocol’s own documentation.
- Any time window mentioned has not already passed.
- You are not being asked to provide a seed phrase, a private key or an authentication code. No legitimate support notice asks for these under any circumstances.
- The action is reversible or, if it is not, the amount involved is small enough that you would accept losing it.
Common mistakes
The most common mistake is treating every notice as urgent. Notices are published on a schedule, and a large share of them are routine maintenance that requires nothing from users. Reacting to routine maintenance produces its own risk: unnecessary approvals, unnecessary gas spend, and a habit of signing things quickly.
The second common mistake is assuming the notice came from where you think it did. Attackers copy the real notice almost word for word and change only the address. Comparing the addresses in the notice against the addresses in the protocol’s own documentation is the check that catches this.
The third mistake is following a notice you found through a search result. Search results and advertisements are not editorial review. Navigate to the protocol directly instead.
When the notice and your screen disagree
If a notice describes a state your own screen does not show, treat that as a signal to slow down rather than a signal to refresh. The mismatch is worth understanding before you act on either side of it.
In practice the explanation is usually one of three things. Your wallet is pointed at a different network than the notice describes. Your address is a different account from the one the notice refers to. Or the condition described has already passed, and what you are seeing is the resolved state.
Check which of the three it is before deciding anything. Acting on a resolved condition can mean an unnecessary transaction, and acting on a condition that applies to a different account can mean approving something that does not apply to you at all.
Keep a record of the decision
Write down the notice date, the affected contract, the action window and what you decided to do, including the option of doing nothing. Most of these situations resolve without any transaction, and a record makes that decision defensible later.
If you did act, record the transaction hash so you can follow it on a block explorer. If you did not act, record why not. Both entries are useful the next time the same protocol publishes another notice.
A note on scope
This guide covers how to read a support notice. It does not rank protocols, estimate returns or recommend any position. If a notice asks you to connect a wallet and sign something, that step deserves its own separate look at the specific contract involved, not just a check of this guide.