# Self-Verified Tokens

> Mark any token as verified for your own organization by supplying its network and contract address. DFNS validates the contract onchain, and the token behaves like every other verified asset in your dashboard, your toggles and your screening integrations. No ticket needed.

- Author: Chris Sutton (CPO)
- Published: 2026-11-11
- Category: Product
- Canonical: https://dfns.co/article/self-verified-tokens/
- All DFNS articles: https://dfns.co/llms-full.txt

---

DFNS now lets organizations verify their own tokens. Give the platform a network and a smart contract address, and DFNS confirms the contract onchain, reads its name, symbol and decimals from the chain, and records the token as verified for your organization. From that moment it is treated like any token on the DFNS verified list. It shows as verified in balances, it appears under the "only show verified assets" toggle, and it is passed to the compliance integrations you have configured for verified tokens. It is available through the dashboard and the API, and once it is switched on for your organization, registering a token requires no involvement from DFNS.

## Why a global list was not enough

DFNS maintains a verified list of tokens and contracts across the networks it supports. Its purpose is to keep spam and scam airdrops out of your view, and for assets like USDC and the major tokens it works well. It worked less well for the tokens institutions actually issue and hold.

A bank's own stablecoin, a tokenized money market fund, a partner's settlement token or a newly listed asset showed as not verified until DFNS added it to the list. That meant a support ticket and a wait, once per token and once per network. In the meantime, the token sat hidden behind the verified-only toggle and carried a warning in history, so an institution's most legitimate holdings looked suspicious to the operations team and to auditors. Integrations configured to screen verified tokens only skipped them, which meant the tokens that mattered most were the ones not being screened. And tokens on test networks and private networks were almost never verified, so a UAT environment never looked like production.

The global list is the right tool for the public market's assets. It is the wrong tool for yours.

## How it works

From the asset or wallet view in the dashboard, or with one API call, you supply the network and the contract address. DFNS then does the work that makes the verification mean something.

It confirms the address is a contract of a supported token standard on that network. It reads the token's metadata, its name, symbol and decimals, directly from the contract, so what is verified is what is deployed, not what was typed. Tokens that do not declare a name onchain cannot be registered, because a token that does not follow the standard is not one the platform should vouch for on your behalf. Tokens already on the DFNS verified list cannot be registered either, since they are already verified for everyone.

The verification applies to your organization only. It does not change the DFNS list and it is invisible to every other customer. A verified token appears exactly as a DFNS-verified one does in balances, in the dashboard's verified-only filters and in the asset lists your integrations receive. Removing a verification is as simple as adding one. If a token's onchain metadata changes, remove it and register it again, since the name always comes from the contract and is never edited by hand.

## Governed like the sensitive action it is

Deciding which tokens your organization treats as legitimate is a control, so DFNS treats it like one. Registering or removing a verified token requires a dedicated permission, which lets administrators decide exactly who may manage the organization's token list. Every registration and removal is signed as a user action and recorded with who did it and when. And because the Policy Engine now governs user actions, you can require an approval quorum before a token is verified, so a single person cannot add an asset to your organization's verified list alone. Requests wait for approval exactly as a transfer does.

## What it does not do

Verification is about trust, not price. Registering a token changes nothing about pricing. If the token is listed on CoinGecko, a price was already available and remains so. If it is not, the balance simply shows no fiat value. DFNS does not let customers set a fixed price for a token, because prices feed policy evaluation and reporting, and a customer-defined price would make both unreliable. For a tokenized deposit worth one dollar by construction, this means the balance is shown in units rather than in dollars until a price source exists.

In this first version, verification applies to balances. Events in wallet history and transfer requests keep the verification status that applied when they happened, as they do today for DFNS-verified tokens. Covering history for future events is a natural follow-up.

And one point worth stating plainly. Self-verification is your organization's own attestation, for your own organization. It is not an endorsement of the token by DFNS, and it does not replace your asset due diligence. It tells the platform what you have already decided to trust.

## Who it is for

Issuers first. Banks and asset managers running the Tokenization Engine, and stablecoin issuers, whose own tokens must be first-class in their custody view from the day they are deployed. Traders and market makers, who list new assets faster than any global list can follow. Payment companies settling in partner or regional stablecoins. And every team running a UAT environment that should behave like production.

For all of them, the effect is the same. The token shows as verified in balances, the screening runs where it should, and nobody opens a ticket.

## Getting started

Self-Verified Tokens are available now, at no additional charge, enabled per organization. Ask your account manager or write to [sales@dfns.co](mailto:sales@dfns.co) to switch it on, then register your first token from the asset view or through the API.

* Learn more about onchain core banking: [dfns.co](https://dfns.co/)  
* Explore the platform and documentation: [docs.dfns.co](https://docs.dfns.co/)  
* Talk to our team: [sales@dfns.co](mailto:sales@dfns.co)