Verification

Not implemented

No part of this works yet — the gateway route is live, but no bot token can be issued, so no method can be called. See implementation status.

Specified in outline only

Third-party verification is B24 in the project TZ, at priority P3 — the lowest tier. The entry is roughly half a page: a model sketch, two method names, and a stated intent. There is no schema, no application process, no policy, and no implementation.

Nothing described here can be applied for, granted or displayed today.

What this is

A verification badge that a third party issues, not the platform.

The idea is that an organisation with real authority over some fact — a bank knowing which accounts are its own, a government registry knowing which entities are registered — can be given the ability to mark users and chats with an icon of their own. The signal is not "GROM checked this account". It is "this specific bank says this account is theirs".

The stated purpose is concrete and local: fraudulent APKs and impersonation channels are a real problem for Uzbek institutions, and a bank being able to mark its own channel is a faster fix than any moderation queue.

Third-party is not official

These badges must look different, and they mean something different

A third-party badge is visually distinct from official platform verification, by design. Conflating them would be worse than having neither.

The trust chain is different too. An official badge is the platform's assertion. A third-party badge is only as trustworthy as the verifier issuing it — it says a particular organisation vouched for this account, and it inherits that organisation's diligence, not GROM's. A careless verifier produces careless badges.

For anyone building a client or a bot that surfaces this: never render a third-party badge in a way that could be mistaken for the platform's own. Always attribute it to the issuing organisation. The verifier's name is part of the signal, not decoration around it.

The model

A bot becomes a verifier by being equipped with verifier_settings, which the outline describes as carrying:

Field	Meaning
icon	A custom emoji id — the badge shown on verified profiles
company	The verifying organisation's name, displayed with the badge
custom_description	Whether the verifier may attach free text to each verification

Two methods operate the badge:

• setBotVerification(bot, peer, custom_description?) — verify a user or chat.
• removeBotVerification — withdraw it.

Neither appears in the method reference: there is no parameter list, no return type, no error set, and no HTTP signature specified for them, so there is nothing to generate. When they are defined they will appear there like everything else.

How a bot is granted verifier status is not specified at all. No application flow, no eligibility criteria, no approval authority, no revocation process. That gap is larger than it looks — it is the entire trust model of the feature, and it is not written anywhere yet.

Questions the outline does not answer

If you represent an organisation that would plausibly want this, these are the things to ask about before planning around it:

• Who approves a verifier, and against what criteria? Being able to hand out badges is a real power and the outline names no gatekeeper.
• What happens when a verifier is compromised? There is no described way to invalidate every badge a verifier issued.
• Can a peer hold badges from several verifiers? And if so, how are they displayed together?
• Does a verification survive the peer changing hands? A channel that is sold, or a username that is released and re-registered, carries a badge that now describes someone else.
• Is there any audit trail? Nothing specifies that verify and unverify actions are logged, or who could review them.
• What recourse does a wrongly verified — or wrongly unverified — account have?

None of these has an answer today. They are listed here so the shape of the gap is visible, because "specified" and "designed" are not the same thing and this one is only the first.

Today

There is no way to become a verifier, no way to be verified, and no badge rendered anywhere in the client. The gateway route is live, but no token can be issued, so none of these calls can be made.

If you are an institution dealing with impersonation on GROM right now, this feature is not the answer — it does not exist, and at P3 with an incomplete model it is not close. Report impersonating accounts through the app's existing reporting, and keep your official presence discoverable from a domain you control.