Article summary
Model wallets, Telegram accounts and phones as separate entities linked by dated evidence, never as automatic proof of common ownership.
Putting a wallet address, TG username and phone in one row creates the impression that all three certainly belong to one person. Web3 marketing needs a relationship model, not a wider contact table. Each identifier exists independently, and every link needs dated evidence.
Three entities answer three different questions
| Entity | What it is | What it cannot prove automatically |
|---|---|---|
| Wallet address | An on-chain address | Natural-person identity |
| TG account | An account observed inside Telegram | Control of a wallet |
| Phone | A communications identifier | Permanent account holder |
The hidden “one row, one person” assumption
One person may manage multiple wallets, a team may share an operating account, and a phone may be reassigned. A single-row model cannot express those realities. It hides them by overwriting old values to keep the spreadsheet visually clean.
What belongs on a relationship edge
Store from_entity, to_entity, evidence_type, captured_at, source and confidence. A user signature, login binding, support confirmation and self-reported form entry do not carry equal evidentiary weight. Inferred relationships must remain distinct from verified ones.
TG Number Checking updates the observation table
TG Registration returns phone and registration observation. TG Activity may return UserID, username, offline time, active days, names, VIP and frozen observations. These update Telegram account observations; they do not create a phone_owns_wallet relationship.
A common false merge
A marketing table maps a phone to username A. An event form maps username A to wallet B. The system then declares that the phone holder controls wallet B. If the username changed, was shared or was entered incorrectly, three systems have been merged falsely. Preserve two source edges and wait for stronger evidence.
Web3 segmentation uses combinations, not identity guesses
- Verified relationship plus explicit permission: enter the stated purpose.
- On-chain event without contact permission: aggregate analysis only.
- TG observation with unknown wallet relationship: do not join profiles.
- Identifier conflict: send to a person or re-verification flow.
TXT keeps a single responsibility
Each line contains only the phone being checked. Wallet, UserID, community role and permission stay inside the organization and rejoin Excel through batch_row. The task file should not become a portable copy of the complete Web3 identity graph.
Relationships need expiry
An account rename, phone reassignment, wallet transfer or permission withdrawal can invalidate an edge. Store valid_from, valid_to and revoked_reason instead of a single current_owner field presumed correct forever.
The views operators actually need
An operating view shows available channel, permitted purpose, recent business event and conflicts needing review. An analysis view aggregates on-chain behavior where possible. Neither view needs to claim that the natural person behind an address has been identified.
The model is valuable because it can say unknown
Telegram’s Privacy Policy shows that platform data has its own processing context. The three-entity model treats uncertainty the same way: when evidence is absent, it leaves the relationship blank and makes later verification more reliable.
