同质化代币 · FT
以余额记录、同类单位可互换。应用可以发行自己的 token，用于支付或其他明确约定的用途。
应用举例
了解同质化代币的用法两个应用确实需要用户在彼此之间转移同一种支付单位时，可以考虑一般可流转 FT。我们建议先明确服务需求；服务额度优先考虑 Credit Token。
把应用的常用操作，写进链的协议。
账户发起支付，创作者签发凭证，服务接受质押。这些操作共享一套身份体系与明确的交易规则，让不同应用可以处理同一组对象。
每个对象，都有地址
DID 是去中心化标识符。在 ArcBlock Chain 上，账户、token、NFT、质押和授权各自都有 DID。同一种地址格式，可以标识谁在操作、转移什么，以及使用哪项授权。拥有一个标识符本身不等于获得访问权。
常用能力，由协议提供
转账、发行 token、资产操作和质押，都有原生交易类型。应用调用这些协议，不必为每项基础操作另写一份智能合约。应用仍需实现自己的业务逻辑与权限流程；协议的变化也需要实现，并由网络采用。
可验证的操作与声明
交易请求执行操作；可验证凭证（VC）是发行方签名的声明。我们的架构演进方向，是让两者共享可验证的表达格式，同时保留各自的职责。统一格式仍在设计中：一份凭证不会自动执行交易，也不必然成为链上记录。
同一套 token 模型，不同的应用规则。
ABT 与应用发行的 token 同属链上的 token 体系，共用地址、余额和交易模型。它的原生身份赋予它特定的网络用途，并不意味着另有一套资产系统。不同 token 的具体使用方式，取决于类型和发行规则。
ABT · 原生代币
公共网络的原生同质化代币，用于网络手续费、Stake for Gas，以及接受 ABT 的应用支付。
应用举例
了解 ABT 的实际用途质押 1 ABT，获得公共网络的交易手续费豁免；也可以在接受 ABT 的服务中支付。适用条件与收费遵循网络和服务规则。
Credit Token · 应用额度
用于应用积分或服务额度，由发行方定义发行与消费权限。发行方可以拥有扣减额度的权限，不能把它理解为可以任意转账的通用代币。
应用举例
理解 Credit 与服务额度用户付费后，应用发放图像生成次数或 API 调用额度，使用时由获授权的服务扣减。应用定义每个单位代表什么，管理消费记录，并交付相应服务。
Curve Token · 曲线规则
BondingCurveToken 按配置的曲线，计算发行与销毁时涉及的储备 token 数量。换算规则由协议明确执行，不只存在于应用后台的一段计算中。
应用举例
了解曲线与发行、销毁计算算力服务可以按已发行单位数量与预设曲线，计算领取 GPU 时长所需的储备 token 数量，用于设计动态资源服务。实际容量的计量、调度与交付仍由服务方实现。
示例用于说明应用方式，不代表这些服务都已上线；token 的属性本身不会完成服务交付。
Stake for X，为具体用途作出承诺。
这里，stake ≠ yield。质押是把 token 锁定，用于支持一项声明的约定，或获得某项服务的使用资格；锁定本身不会自动产生奖励。X 就是具体用途。这套协议适用于任何 token，同时遵守该 token 的权限与服务约定。
声明约定
明确用途、token、数量、有权扣罚的一方及退出等待期，规则中也要明确扣罚资金的去向。
按约定使用
服务根据质押提供相应能力。约定的扣罚条件发生时，由获授权的一方发起扣罚，可扣除部分或全部质押。锁定的余额不能随意消费。
按规则释放
申请解除质押并经过等待期后，可取回符合释放条件的剩余金额。Stake for Gas 用 ABT 获得免交易手续费资格；其他服务可以定义自己的 X。
连接 Ethereum，专注应用。
ArcBlock Chain 与 Ethereum 是独立的 Layer 1 网络，Base 则是 Ethereum 的 Layer 2。ABT 通过桥连接这些环境，按 token 数量 1:1 转换。原生链的实际用途，与 Ethereum 生态的持有、转账基础设施各有分工；这种互补是我们的设计选择。
L1 · NATIVE ABT
ArcBlock Chain
原生 ABT · 应用支付、Stake for Gas 与 Stake for X。ABT 在 ArcBlock 中的实际用途在这里执行。
L1 · ERC-20
Ethereum
ERC-20 ABT · 使用广泛支持的 Ethereum 钱包与基础设施持有和转账。
ETHEREUM L2
Base
Ethereum L2 生态中的 ABT · 按各条跨链路径的规则，在桥支持的网络之间流转。
1:1 指 token 数量的对应关系，不是扣除费用后的到账数量。支持路径、确认时间、限额与可用性以桥的当前界面和规则为准。桥有自身的安全假设，不会让不同网络共享同一套共识。
历史、当前状态与查询，各司其职。
账本架构将原始交易历史，与应用使用的状态和查询视图分开。检查点通过哈希汇总一段记录，使核验可以对照已知检查点进行。它证明记录与参考的一致性，不会自动证明现实世界中的每项声明都是真实的。
Ledger
只追加的交易历史，保存已接纳的操作记录。
State
按照交易规则推导出的余额、持有关系与权限。
Index
面向应用的查询视图，与原始历史分离。