Keep token identity clear through contract migration

A migration is more than a new token label

Contract migration support connects the old token details with the new ones across the profiles people consult. It helps your community recognize which contract is current while your project changes its name, ticker or logo.

The first useful task is to decide what changes and what stays the same. Record both contract addresses and chains, then confirm the name, ticker, logo and official project links. If the token identity remains the same, explain that relationship plainly. If the project is changing more than its contract, spell out each change separately.

Say your team changes a logo and ticker but keeps the same contract. That calls for a focused profile update, not a migration explanation. When the contract changes too, the request should connect the old and new addresses and describe the transition. We can coordinate either kind of update, with the work based on the platforms and details you want reviewed. For other profile changes on DEXTools and DEXScreener, see DEXTools and DEXScreener profile updates.

Start with one approved migration record

A shared record gives every platform request the same source facts. We review it before preparing submissions, so missing details can be resolved with your team instead of guessed at.

1. Confirm the change. Add the old and new contract addresses, chain names and migration stage. Mark which contract users should treat as current, and when that changes if your plan includes a transition period.
2. Approve the token identity. Write the exact name and ticker for display. Add current logo files, the project website and official social links. Keep spelling consistent across the record and public materials.
3. Show the connection. Include a public migration explanation if available, plus a project contact who can confirm facts or answer questions. If circulating supply information also changes, identify that as a separate task; circulating supply verification covers that work.

Check each address against your approved project records, character by character. Then compare the website, announcement and explorer details with the record. We use this simple comparison to flag mismatches before requests go out. Your team approves the final facts, and we prepare each platform request from that approved version.

How do tracker and screener updates differ?

CoinMarketCap, CoinGecko, DEXTools and DEXScreener have separate profiles and update routes. We prepare a request for each agreed destination, rather than assuming one announcement will change every public display.

CoinMarketCap and CoinGecko

For these profiles, we organize the requested name, ticker, logo and contract context with the project materials that explain the change. If you also need support beyond a migration update, see our CoinMarketCap listing support and CoinGecko listing support.

DEXTools and DEXScreener

We check which token or pair details are visible and identify the profile information that needs attention. A profile edit and a migration announcement are different tasks, so we keep them clear in the request.

We track each destination separately. That makes it easier for your team to see what was submitted, what is visible and what still needs a reply. For broader tracker coverage, listings on other crypto trackers can be considered separately. The update record stays useful even when the platforms show changes at different times.

Keep the handoff clear after the requests go out

The work includes a record of requests and a check of what appears on public profiles. That gives your team something concrete to use when coordinating community messages and migration support.

Imagine a developer who writes docs but not posts, just after a good thread brings new faces. The developer wants newcomers to find the right contract without searching through old messages. We would check the approved migration facts, prepare the profile requests and report what is visible afterward.

Your handoff can include:

• The platforms and profile details included in the agreed work.
• A record of submitted requests and platform follow-up.
• A note of visible changes, open items and project-side actions.

Each platform decides whether, when and how its own profile changes, and may ask for clarification. We can deliver the agreed preparation, coordination and checks, but cannot set platform review times or promise approval. Keep one contact ready to answer questions, and describe a change as complete only after checking the relevant public profile.

Carry the same token facts into the wider rollout

Profile updates work best when the rest of your migration materials tell the same story. Your website, announcement, explorer information and community replies should point to the same current contract and use the approved name and ticker.

Suppose a community moderator receives a question while one profile still shows earlier details. A shared migration record helps them answer with the approved explanation and current project links. It also helps your product lead, communications lead and platform contact avoid sending different versions of the change.

We can coordinate this work alongside explorer token information and logo updates and wallet logo and token list inclusion. The wider listings and verification plan can also be part of your rollout. These are separate tasks, so we include them only when they fit.

To begin, send us the old and new contract addresses, chain, target platforms, approved token details and migration announcement or draft. Brand Community will check the record, flag missing facts and map the platform requests for your approval.

How it works

1. Agree which profiles need changesWe list the platforms and requested contract, ticker, name and logo updates. Your team confirms the approved source facts.
2. Gather the migration materialsYou share the explanation, project links, logo files and a contact for questions. We flag any mismatch before requests are prepared.
3. Prepare each platform requestWe match the request to the profile details being changed, then share the facts with your team for approval.
4. Coordinate submissions and repliesWe coordinate the agreed requests through the applicable routes and record follow-up questions and responses.
5. Check the public profilesWe note which changes are visible, which items remain pending and whether your team needs to respond.