Telegram创始人Pavel Durov于2026年7月21日表示，Telegram将在当年夏季把原生、非托管的Gram Wallet带到Telegram应用，并把它描述为面向十亿级用户群的推广计划。准确理解应是“计划向庞大的Telegram用户基础推出”，而不是“十亿人已经开通、验证或正在使用钱包”。
对Web3团队而言，这条消息的重要性不只在于多了一个钱包入口，还在于钱包能力更靠近聊天、社群和机器人。但钱包入口、Telegram账号、手机号码、链上地址和营销许可仍是不同的数据对象，不能用一个字段替代另一个。
先记住：非托管意味着用户控制密钥与资产，也意味着恢复、钓鱼识别和转账确认的责任更多落在用户本人。任何运营流程都不应索要助记词、私钥或一次性验证码。
2026年7月的公开信息说了什么？
Pavel Durov的公开帖文使用了“bringing a native non-custodial Gram wallet to every Telegram app”的表述，并称即时、零手续费的加密交易将面向Telegram的十亿级用户群。Telegram中的@Wallet公开入口目前展示USDT、Gold、Bitcoin、GRAM等资产及支持机器人。
这两项资料能证明产品方向和公开入口，但不能证明每个国家、每个客户端和每个账号已经获得完全相同的功能。钱包可用性、资产、费用、身份验证和限制都可能因地区与版本不同，执行前必须在真实账号内核对。
| 表述 | 是否稳妥 | 原因 |
|---|---|---|
| Telegram宣布推广原生非托管Gram Wallet | 是 | 与公开帖文一致 |
| Gram Wallet已经覆盖十亿用户 | 否 | 潜在覆盖不等于实际启用 |
| 所有地区都支持同一资产与功能 | 否 | 需按账号和地区核验 |
| 钱包用户就是高价值客户 | 否 | 资产与购买意向均无依据 |
“非托管钱包”改变了谁的责任？
在非托管模式下，用户通常直接控制密钥或恢复凭据，而不是由中心化平台代为保管。这带来自主性，也意味着丢失恢复材料、签署恶意交易或把资产发往错误地址时，未必存在传统账户那样的找回机制。
项目方的责任是让风险可见：明确官方入口和合约地址，解释签名内容，避免在私聊中索要敏感凭据，并为仿冒机器人、假客服和钓鱼链接建立举报路径。客服可以解释流程，但不应远程接管钱包。
钱包入口靠近聊天，会形成什么新场景？
社群可以在公告、活动、奖励领取和点对点转账之间缩短路径。机器人也可能承担余额查询、任务提醒或支持导航。不过，任何涉及资产的动作都应在用户主动触发后发生，并显示网络、币种、金额、地址和费用。
运营人员不应把“加入加密群”“打开钱包入口”或“点击资产内容”直接归类为投资能力。真正的用户分层仍应来自自愿提供的需求、产品行为、订单或服务关系，而不是从钱包概念推断财富。
| 场景 | 可以使用的信号 | 不应推断 |
|---|---|---|
| 钱包使用教学 | 用户主动选择的教程步骤 | 资产余额 |
| 社区活动提醒 | 明确订阅与活动报名 | 持币意向 |
| 链上奖励核对 | 用户提供的钱包地址与交易哈希 | 手机号所有人的全部地址 |
| 客服排障 | 错误码、网络、公开交易信息 | 私钥、助记词或验证码 |
钱包、Telegram账号和手机号应怎样分层？
建议把CRM拆成四层：customer_id保存业务主体；telegram_channel保存手机号、TG UserID或用户名及确认日期；wallet_identity保存用户主动提交的钱包地址、链和验证方式；permission保存每项联系与数据用途。各层通过内部ID连接，不把用户名当手机号，也不把地址当实名身份。
钱包地址通常是公开标识，但“公开可见”不等于可以无限收集或与个人资料任意拼接。只有业务确有需要且用户知情时才建立关联，并记录来源、用途、验证时间和删除条件。
TG筛号在这套流程中能做什么？
如果Web3团队已有合法来源的客户号码，可以把号码整理为UTF-8 TXT，每行一个手机号，通过爱普筛Telegram（TG）服务选择TG筛开通或筛活跃。筛开通返回手机号与是否开通；筛活跃可增加TG UserID、用户名、离线时间、活跃天数、姓名、VIP和冻结状态。
这些Excel字段都不包含钱包余额、持币种类、链上收益或投资偏好。TG VIP也不能解释为高净值。若业务需要钱包地址，必须由用户在清楚的交互中主动提供或验证，不能从号码检测结果推算。
Web3团队上线前的风险矩阵
| 风险 | 可能后果 | 控制措施 |
|---|---|---|
| 假钱包机器人 | 用户泄露资产或凭据 | 官网公布唯一入口、固定举报渠道 |
| 把潜在覆盖写成实际用户 | 宣传失真 | 保留发布日期和地区限定 |
| 混合手机号与钱包画像 | 隐私与合规风险 | 分层存储、最少字段、用途控制 |
| 客服索要敏感信息 | 账户和资产风险 | 脚本明确禁止助记词、私钥与验证码 |
| 自动空投给未知地址 | 诈骗、浪费与制裁风险 | 用户主动领取、地址校验与规则审查 |
怎样验证真实可用性？
- 只从Telegram应用或官网公布的入口进入；
- 记录客户端版本、账号地区和测试日期；
- 查看钱包类型、支持资产、网络、费用和恢复说明；
- 使用不含重要资产的测试账户完成最小流程；
- 检查退出、备份、客服与举报路径；
- 把测试结果与宣传文案逐项对照。
如果目标账号没有入口，正确结论是“当前账号未验证可用”，而不是“功能不存在”或“所有人都能使用”。如果入口存在，也不要立即扩大到全部客户；先完成安全审查和小范围用户教育。
适合写入运营SOP的最后一页
SOP应明确官方入口、允许的客服信息、禁止索取的凭据、地区差异、钱包地址验证、事件响应和版本复核日期。每次产品更新只修改受影响的事实与步骤，不顺便扩大TG筛号的产品声明。
一条实用底线是：聊天负责沟通，钱包负责资产操作，筛号负责渠道层检测，CRM负责业务关系和许可。四者可以连接，但只有在字段来源和用途清楚时才能合并。
