在 NEAR 上往一个合约转代币，有可能出现“转出去又被退回一半”的景象。这不是故障，而是 NEP-141 同质化代币标准写死的语义：它把“转账顺带让接收合约干活”定为标准能力，用不完的部分由协议机制原路退回。规范状态为 Final，创建于 2022 年 3 月，取代老标准 NEP-21，并声明与存储管理标准（NEP-145）互相咬合。读懂这套接口，比在浏览器里碰运气有用得多。
三个动作方法、两个查询方法
核心接口很小：ft_transfer（普通转账）、ft_transfer_call（转账并调用）、以及视图方法 ft_total_supply（总供应量）和 ft_balance_of（单账户余额）。两个转账方法都要求调用者附带 1 yoctoⓃ 的押金——规范的理由不是收钱，而是把“只调函数不带资产”的低风险调用与真实用户签名动作区分开的防误操作闸门，这条在 NEAR 转 NFT 为什么要附 1 yocto：NEP-171 的异步模型差异 有展开。金额一律是十进制字符串，底层是 128 位无符号整数（上限 2 的 128 次方减一），用字符串是为了躲开 JSON 数字在 2 的 53 次方以上的精度陷阱。还有一个对合约开发者的重要提醒：代币合约所在的账户不应留有访问密钥，防止部署后被改动。
转账加调用的五步流水线
ft_transfer_call 多带一个自由格式的 msg 参数，告诉接收合约怎么处理这笔钱。规范把标准流程编号成五步：一、你对代币合约调用 ft_transfer_call；二、合约把 amount 记到你账下转给接收合约；三、代币合约紧接着调用接收合约的 ft_on_transfer；四、接收合约继续它自己的跨合约调用；五、 Promise 链回到代币合约自己的 ft_resolve_transfer 收尾。关键在返回值的约定：ft_on_transfer 必须报告没用掉的代币数量（字符串形式，比如收了 10 只用了 9 就返回 “1”），ft_resolve_transfer 据此把差额退还发起人；整条 Promise 链失败，转账整体回滚，就像什么都没发生。规范给的算例：转出 100，接收方只用掉 80，resolve 返回 “80”——这个数字才是你实际花掉的量。另一条容易被忽略的硬规则：ft_resolve_transfer 禁止除合约自身以外的任何账户调用。
精度不在这个标准里
规范明说：小数位（decimals）不属于核心标准——执行转账不需要它，最小值永远是整数 1 个代币；要标准化地声明精度，去实现配套的 fungible token 元数据标准 NEP-148。这就是为什么钱包显示的余额会差数量级：代币合约声明的小数位读错，1000000 会被当成 1。给 wBTC 这类 8 位精度的例子，规范用 10 的 8 次方表示换算；DAI 是 18 位，wNEAR 是 24 位。核对精度看元数据，不看界面文案。
余额为零之前，先想过注册吗
NEAR 的账户存储有押金机制，代币合约要为每个登记用户垫付存储成本，所以 NEP-141 设计与存储标准互操作：往键值表里加人要记存储变化，从表里删人可以顺带退回那份名义上的 Ⓝ。落到用户体验上，就是“第一次收某个代币要先交押金登记”“卖出或退出后押金随状态清理退回”——收押金、查押金、退押金的统一接口是 NEP-145，细节在 NEAR 上先交押金再登记：storage_deposit 与两条退钱的路 拆过。没登记就转来的币可能卡在合约里等一套认领流程，这也是“转了却不见”的常见答案之一。
事件：给浏览器和钱包的流水账
规范在动作接口之外规定了一套事件（扩展 NEP-297 事件标准）：ft_mint、ft_burn、ft_transfer 都支持批量数组，载荷带 owner_id、金额与可选 memo。浏览器和钱包的余额索引靠这些事件重建，但注意规范的坦白：事件是可选扩展，个别合约可能不发；显示代币名称与精度靠的是元数据方法。读事件载荷也有自校验的纪律：每条 EVENT_JSON 外裹 standard 与 version 字段（本标准的 standard 取值为 nep141，示例中 version 为 1.0.0），核对时先确认这两个字段再进 data 数组；金额同样以十进制字符串承载，直接按 JSON 数字解析又会踩回精度陷阱。用户排查一笔到账的动线因此是三层：交易回执找 ft_resolve_transfer 的返回值，确认实扣金额；区块浏览器的账户动作里核对 ft_transfer 事件；余额查询用 ft_balance_of 对照。涉及资产的转账与登记都不构成投资建议，机制描述以 NEP-141 官方仓库原文的 2026-10 版本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。