Contract migration updates across token profiles

Should we update every profile in one sequence?

4 destinations can move together. 1 profile can move first. Pick the route that matches your launch order.

Choose a shared sequence if the contract, name, ticker and logo are final. Choose a staged sequence if your team needs to update one public profile before another. We map each destination separately. A request for one service does not update every profile.

This service fits announced migrations and completed rebrands. It also suits teams finding conflicting names or contract details on existing profiles. If the new contract or ticker remains undecided, hold profile requests. First, approve one canonical version with your project contact.

4 checks before profile requests

4 checks take the update from project facts to a trackable request. We separate your approved information from platform work. Then we record each destination on its own.

1. Confirm the change: list the former and current contract, chain, name, ticker and logo.
2. Match the evidence: connect the migration explanation to the project’s approved details.
3. Prepare requests: adapt the agreed information for each selected profile.
4. Track the result: log preparation, submission status and visible profile changes.

The order matters. A new contract alone does not settle whether the ticker, logo or official links should change too. We ask you to approve those fields before preparing requests. If supply information is changing, include it in the source materials. You can also consider circulating supply verification.

Your project contact approves the final facts. We check each request against those facts. This gives your team a clear correction point before submission. It prevents different versions from reaching separate destinations. The work log also separates requests we prepared from changes visible to the public.

What we need from your project

7 inputs give us a usable starting record. Send what is final. Flag anything still under review.

• Contract addresses: old and new, with the relevant chain for each.
• Token identity: approved name and ticker, including previous versions.
• Logo files: the intended public asset, not several unapproved alternatives.
• Project explanation: an announcement or other project-owned migration note.
• Official links: website and social channels that should appear on profiles.
• Profile URLs: CoinMarketCap, CoinGecko, DEXTools and DEXScreener pages you want updated.
• Existing correspondence: platform replies or requests for more information.

One authorized contact should confirm the canonical details. That prevents conflicting versions from entering the update record. If your project has multiple contracts or networks, list each separately. Do not assume one set of fields applies to every asset.

We compare the supplied facts before preparing requests. We flag missing or mismatched information for your review. For CoinMarketCap listing work beyond migration, see CoinMarketCap listing support. For explorer metadata or logo changes, check explorer token information updates.

Which update window applies to each profile?

4 platform destinations need separate status checks. Our working sequence starts with your approved details. Then we record each request and any public change.

A platform-specific update does not replace checks on other profiles. We keep one status entry per destination. We compare visible fields with the same approved source. For CoinGecko, existing profile changes and new listing work are different requests. CoinGecko listing support covers listing-focused work.

Our preparation window follows the readiness of your inputs and approvals. We share a working sequence after checking the profile list. Each status entry shows what is prepared, what is submitted and what remains visible for review.

Platform decisions and your next move

3 checks keep the record useful: approved facts, request status and visible fields. Each platform controls its own review and publication decisions. We cannot promise acceptance or synchronized changes across CoinMarketCap, CoinGecko, DEXTools and DEXScreener.

• Fact check: one project contact approves the contract, chain and identity fields.
• Status check: each destination has its own preparation and submission entry.
• Visibility check: public fields are compared with the approved change map.

If a platform asks for more evidence, we review its response. Then we identify what your team needs to provide. If a public page remains inconsistent, we log the mismatch and recommend a follow-up request. We do not mark a pending request as a completed update.

At DigitalMedia1, the account review checks source facts against every profile link before requests are prepared. You receive a change map and a record that separates our work from platform status.

Send the old and new contract details, approved token identity and affected profile links. We’ll return a written quote within 2 working days.

How it works

1. Confirm the changeSend the old and new contract, chain, approved identity and profile links. We confirm which destinations you want included.
2. Check the source factsWe compare the details and evidence. Then we flag missing fields or conflicts for your contact to resolve.
3. Prepare each requestAfter your approval, we prepare the agreed profile updates. We log each status separately.
4. Review visible fieldsWe compare public profiles with the approved change map. We record any open mismatches.