PAS 概述与方案对比

如何引入 PAS 库

依赖配置

在发行方包的 Move.toml 中声明对 pas 和（若需注册 Command）ptb 的依赖：

[package]
name = "your_coin"
edition = "2024.beta"

[dependencies]
pas = { local = "../pas" }   # 或 git = "https://github.com/MystenLabs/pas" }
ptb = { local = "../ptb" }   # 仅当需要 set_template_command 时
sui = { git = "https://github.com/MystenLabs/sui", rev = "..." }

常用 use 语句

发行方模块中通常需要：

use pas::namespace::Namespace;
use pas::policy::{Self, Policy, PolicyCap};
use pas::chest::{Self, Chest, Auth};
use pas::request::Request;
use pas::send_funds::{Self, SendFunds};
use pas::unlock_funds::{Self, UnlockFunds};
use pas::clawback_funds::{Self, ClawbackFunds};
use pas::templates::Templates;
use ptb::ptb;  // 用于 move_call、ext_input、object_by_id 等

解析函数里会用到 request.data()、request.approve(...)，以及 send_funds::sender/recipient/funds 等访问器。

什么是 PAS

Permissioned Assets Standard（PAS） 是 Sui 上用于发行和管理许可型资产的框架，面向需要合规约束、转移限制和监管控制的同质化代币场景（如证券型代币、稳定币、合规稳定币等）。资产只能存放在 Chest 中，转账通过 Request（SendFunds / UnlockFunds / Clawback） 发起，并由发行方定义的解析逻辑（含 KYC、白名单、限额等）批准后才会完成。

参考：MystenLabs/pas、PR #25 KYC-compliant coin example。

设计目标

• 许可转移：所有转账必须经过 Chest，并由与 Policy 绑定的自定义规则批准。
• Chest 架构：代币只能存在于 Chest 中，每个地址（或对象）对应一个派生 Chest，便于发现与 RPC 查询。
• 灵活策略：每种代币类型对应一个 Policy，可配置不同动作（send_funds、unlock_funds、clawback_funds）所需的审批类型。
• 可选 Clawback：在注册时选择是否允许监管收回（clawback），满足合规需求。

核心概念一览

与既有方案的详细对比

下表对比 PAS 与本书前面介绍的几种「受限/合规」方案，便于按场景选型。

选型建议

• 只需黑/白名单、无需每笔自定义逻辑：DenyList 受监管代币即可。
• 同质化 + 每笔转账都要做 KYC/限额/白名单等自定义检查：用 PAS，在 resolve 里实现你的规则。
• 同质化 + 仅限在自家应用内 transfer/spend：闭环 Token + TokenPolicy 更轻。
• NFT 版税、Kiosk 内交易与锁定：用 Kiosk + TransferPolicy。

Coin、受监管 Coin、闭环 Token 与 PAS 详解

下面从「存储与转移模型」「谁做校验」「能表达什么规则」「典型用途」四方面，把 标准 Coin、DenyList 受监管 Coin、闭环 Token、PAS 说清，并说明为什么要 PAS。

1. 标准 Coin（普通代币）

小结：Coin 是「完全开放」的同质化资产，适合不需要合规或转移限制的场景。

2. DenyList 受监管 Coin（黑名单代币）

小结：受监管 Coin 在「标准 Coin + 黑名单 + 可选全局暂停」范围内做合规，不能做按笔的 KYC、白名单、限额、自定义逻辑。

3. 闭环 Token（Closed-Loop Token）

小结：闭环 Token 是「同质化但非自由流通」的 Token，规则由 Rule + prove 表达，适合应用内闭环；不是「每笔都经发行方或链下 KYC 审批」的模型。

4. PAS（许可资产标准）

小结：PAS 是「每笔转移都可被发行方自定义逻辑约束」的同质化资产框架，且支持 Clawback 与可控解锁。

为什么要 PAS：三种方案覆盖不了的场景

• Coin：不限制谁转、转给谁、转多少，无法做合规或每笔审批。
• Deny Coin：只能「禁止名单内地址」，不能做「仅允许 KYC 用户」「单笔限额」「每笔经发行方逻辑放行」。
• 闭环 Token：规则是「满足 Rule 即放行」，规则在链上固定（如成员集、时间锁），不能做「每笔由发行方或链下 KYC 审批」；且一般无 Clawback、无「解锁到链上」的标准路径。

PAS 要解决的问题恰恰是：

1. 每笔转移都可执行自定义合规逻辑（KYC、限额、白名单、黑名单、监管审批等），且逻辑在发行方自己的 Move 模块里，可演进、可升级。
2. 需要 Clawback：监管或司法要求时，发行方能从指定 Chest 收回资产。
3. 需要可控「解锁」：在合规允许时，将资产从 PAS 体系解锁为链上通用余额（如赎回为稳定币或法币通道）。
4. 钱包/SDK 友好：通过 Templates + Command，链下可以按「审批类型」自动拼出解析 PTB，而不必手写每家的解析逻辑。

因此：当你要做「同质化 + 每笔可审批 + 可选 Clawback/解锁」的合规资产时，应选 PAS；若只需黑名单或应用内闭环，用 Deny Coin 或闭环 Token 更简单。

用途对比一览

小结

• Coin：自由转移、无合规；Deny Coin：黑名单 + 可选全局暂停，无每笔逻辑、无 Clawback；闭环 Token：Rule + ActionRequest，应用内闭环，无每笔发行方审批、一般无 Clawback；PAS：Chest + Request + 发行方解析，每笔可自定义合规、可选 Clawback 与 Unlock。
• PAS 面向许可型同质化资产，通过 Chest + Request + Policy 解析 实现「每笔转移都可被发行方规则约束」；为什么要 PAS：当需要每笔 KYC/限额/白名单、Clawback 或合规解锁时，Coin / Deny Coin / 闭环 Token 无法满足，选 PAS。
• 选型时结合「用途对比一览」表：按需求看哪一列打勾，即可在四种方案中做出取舍。