加密货币项目中的代币归属：为什么需要以及如何实施

Vesting（归属）是项目 Token 经济学的一部分，它可以控制 Token 的价值。在本文中，我们将讨论项目参与者之间 Token 分配的各种技术、方法和模式，并展示几种用于 Token 归属的流行解决方案。你将能够找到项目在实施归属时出现的常见问题的答案。

什么是 Vesting？

Vesting 是在 Token 销售或其他形式的加密货币资产销售后，Token 分配的各种方法、途径和模式的统称。

在传统金融中，“vesting”一词指的是在特定的时间段之后或满足某些条件后，获得控制资产（例如股票或养老金储蓄）的权利。例如，员工可能会收到公司股票，但无法立即出售。这确保了他们对公司成功的既得利益，并防止了来自卖方的市场压力，这些压力可能会压低股价。

在加密货币的背景下，Vesting 是项目 tokenomics 的一个组成部分，该部分的设计考虑了人类心理学和数学模型。这有助于将 Token 价格控制在一定范围内（至少在一定范围内）。Token 销售通常包括多个阶段，例如种子轮、私募轮、战略销售、ICO 等。在这些阶段之间，Token 价格可能会有很大差异。

一个经过精心设计和平衡的 Token 随时间推移的分配计划可以管理价格波动和整体项目完整性。它尤其可以防止在交易所上市后立即出现大规模 Token 抛售，从而实现长期价格控制。Vesting 还可以用于激励项目参与者，例如开发人员或营销人员，他们会收到 Token 作为他们工作的奖励。

重要的是要注意，并非所有 Token 都受 Vesting 的约束，因为这会严重影响流动性。通常，Vesting 涉及锁定总 Token 供应量的 10-20% 左右，其中可能包括分配给团队、投资者、顾问等的 Token。

Vesting 的类型

有两种最流行的模式：基于日历的 Vesting 和基于里程碑的 Vesting。

基于日历的 Vesting

基于日历的 Vesting 的分配模型可能如下所示：

• 早期投资者：总共分配给他们 100 万个 Token。在开始后的第一个月，他们会收到分配给他们的 Token 的 5%。他们剩余的 Token 在第二个月和第三个月保持锁定状态。在第四个月，他们收到 20% 的 Token，然后在随后的每个月收到剩余 Token 的 25%。
• 公众投资者：总共分配给他们 500 万个 Token。在最初的三个月内，他们无法申领任何 Token；他们的资金仍然处于锁定状态。Vesting开始和第一次 Token 分配之间的这段初始时期称为 cliff period（锁仓期）。对于公众投资者来说，这个 cliff period 持续三个月。之后，他们每个月收到 20% 的 Token。

Cliff（锁仓期）——Vesting 开始和解锁后第一次支付 Token 之间的时间。

• 顾问：总共分配给他们 500,000 个 Token。在 10 个月的时间里，他们每个月收到 10% 的分配。
• 开发团队：总共分配给他们 100 万个 Token。为了提高积极性和信任度，他们在一年后收到很大一部分 Token。在第一个月，解锁 5%；然后在第四个月解锁 10%，在第六个月解锁 15%，在第八个月解锁 25%。剩余 45% 的 Token 保持锁定状态，直到 Vesting 开始后的第十二个月。
• 市场营销：总共分配 500,000 个 Token，以维持营销活动。这些 Token 将在一年内解锁。在第一个月，可以访问总金额的 12%，然后在随后的每个月访问 8%。

表格：基于日历的 Vesting 计划

基于里程碑的 Vesting

在基于里程碑的 归属 中，Token会随着时间的推移逐渐解锁，但没有明显的期限。最常见的类型是线性 归属，但还存在其他类型，例如阶梯式、二次式等。

在线性 归属 中，Token会随着每秒的过去或创建新区块而解锁。在阶梯式 归属 中，Token会根据预定的时间表解锁。

归属 计划定义了资产权利转移给受益人的速度。期限可能会因协议而异，通常为 1 到 4 年。归属 计划通常以图形方式表示。

阶梯式 归属 示例，每年分配总Token供应量的 25%。

4 年阶梯式 归属 示例，带有年度锁仓期

基于里程碑的 Vesting 也可以有一个 cliff period。例如，如果 Token 销售从 1 月开始，cliff period 为 6 个月，则付款将仅从 7 月开始，并且所有 Token 将被锁定到那时。

你可以使用服务 tokenterminal.com 查看特定加密货币的时间表。为此，请访问仪表板，选择项目，然后查看 Vesting Schedule 选项卡。以下是 Aptos 项目的 归属 计划。

Aptos 项目的 归属 计划

Token 支付

Token 支付根据前面提到的时间表进行。有两种主要的支付方法：push 和 pull。

Pull（拉取）： 使用拉取方法，受益人可以通过发起区块链交易来申领他们的 Token。Vesting 结束后，Token 将被解锁，但仍保留在智能合约中，直到受益人将其转移到他们的钱包或指定的地址。这种方法让 Token 持有者可以更好地控制他们收到 Token 的时间，因为他们可以选择特定的 Token 检索日期。

示例：根据分配计划，每个月解锁总 Token 的 10%。这意味着你可以在半个月后申领 5%，或者选择三个月不申领任何 Token，然后一次性收到 30%。

Push（推送）： 使用推送方法，被授予的 Token 会自动转移到受益人的地址，而无需他们执行任何操作。

这样，受益人无需为 Token 申领支付交易 gas 费，但需要权衡：受益人对 Token 转移的时间控制较少，因为它取决于智能合约中建立的支付计划和规则。

关于技术实施的问题

在这里，我们总结关于 Vesting 的一般信息，并提供智能合约中实施的技术解决方案的概述。

尽管核心 Vesting 理念很简单（购买后锁定 Token，然后按照时间表解锁），但技术实施可能会因项目而异。产品经理的创造力和去中心化原则决定了他们自己的规则。因此，在智能合约上实施它之前，需要回答以下几个问题。

1. 将使用哪种类型的 Vesting？（线性、阶梯式、基于日历等）
2. 所有用户都将具有相同的时间表，还是每个受益人的时间表都不同？
3. 何时锁定 Token？在 Token 销售期间还是为项目利益相关者锁定？（例如，为开发人员或营销人员进行 Vesting）
4. 如果在 Token 销售期间，哪些销售阶段应触发 Token 锁定？（公开、私募等）
5. 如果是为团队提供的，将有多少个地址参与 Vesting？
6. Vesting 何时开始？在什么时间点？（销售开始后，销售结束后，购买时）
7. 是否有 cliff period？
8. 在 cliff period 期间可以对 Token 执行哪些操作？
9. 在 cliff period 期间禁止对 Token 执行哪些操作？
10. 购买后如何锁定 Token：在用户的钱包上、在单独的合约上，还是两者兼有？（例如，用户收到份额 Token，稍后将这些 Token 兑换为锁定的基础 Token）
11. 如何解锁和支付 Token？
12. 将使用哪种方法（push 或 pull）？
13. 支付计划是什么？
14. 谁可以设置支付计划以及何时设置？
15. 例如，如果是为团队提供的 Vesting，那么 Vesting 是否可以在智能合约上没有 Token 的情况下开始，或者在支付之前提取 Token？这将如何影响 Vesting 开始时间？

在 Vesting 实施过程中可能会出现这些以及许多其他问题。下面，我将描述不同的 Vesting 变体在智能合约中如何在架构上呈现，以及它们的优缺点。

Vesting 的实施方法

1. 在 ERC20 Token 智能合约上

在加密货币项目中实施 归属 的一种方法是直接将 归属 合并到Token的智能合约中。此方法涉及将私募智能合约与Token智能合约链接（或者销售功能也应在Token智能合约上）。在销售过程中，会为特定用户锁定一定数量的Token。如果发生多轮私募销售，还可以分配一个 归属 的标识符。

Token智能合约中的付款计划可以由合约管理员或专门为此目的创建的其他角色设置。

结果：

优点：

1. 基本（锁定）Token保存在用户的钱包中。但是，如果更改了余额显示功能，则此点不能被视为优点。可能会出现混淆，因此建议仔细考虑余额显示（锁定和解锁）。
2. 无需启动单独的交易来申领Token。它们会自动可用，这意味着用户的余额会以一定的间隔增加。

缺点：

1. 保持Token智能合约的代码“干净”且易于阅读被认为是良好的做法。任何其他逻辑都需要彻底检查，理想情况下，需要进行良好的审核。
2. 引入新功能不可避免地会导致添加其他角色，这会增加黑客攻击和错误的风险。智能合约中最脆弱的部分始终是人为因素，这些人可以在智能合约中修改某些内容或设置不正确的参数。将需要更复杂的保护和管理功能管理。
3. 为了正确显示余额并在Token转移期间执行检查，标准方法（如 transfer 和 balanceOf）将需要修改。此外，如果单独的智能合约处理销售，则Token会获得外部依赖项。这也增加了潜在漏洞的可能性。因此，找到可靠且最佳的解决方案可能需要更多时间。
4. 如果余额显示保持不变，则会出现一个问题，即Token存在，但有必要检查可以花费的部分以及以后将解锁的部分。
5. 此解决方案增加了错误和潜在威胁的风险。由于多个私募销售轮次，复杂性进一步增加，从而导致几个不同的 归属 计划。
6. 归属 结束后，智能合约将包含“死”代码。Token转移验证将在合约的整个生命周期中进行，这会稍微增加 gas 成本。

总之，此实施可能不是最佳解决方案。归属 功能仅在特定时期内是必需的，如果它以某种方式与Token相关联，则此类连接和“死”（未使用）代码将无限期地保留。我什至没有找到具有此类实施的智能合约代码的合适示例。

2. 通过智能合约系统实施 Vesting

Vesting 实施的另一种方法是使用智能合约系统。 例如，让我们考虑一下 TON 项目 (Tokamak Network Token)。 该生态系统将目标 Token (TON)“划分”为充当目标 Token“份额”的 Token。 在每个销售阶段，购买者都会收到不同类型的 Token，例如 SeedTON、PrivateTON 或 StrategicTON。 系统中总共有九个此类 Token，整个供应在它们之间分配。 这些 Token 具有相对于目标 Token 的自身价格，并且每个 Token 都有自己的支付计划。 根据此计划，份额 Token 随后将交换为目标 Token，并且在此过程中会销毁份额 Token。 这是通过一个特殊的智能合约 Swapper 完成的，而目标 Token 也单独存储。 份额 Token 无法转移——一个单独的智能合约管理着这一点。

该生态系统由大约 15 个智能合约组成。 目标和子 Token 以一种独特的方式开发（从外部来看，它们是 ERC20 Token，但在内部以不同的方式实现）。 该架构是基于项目复杂的 Token 经济学构建的。 你可以在此仓库中探索 TON 智能合约。

结果：

优点：

1. Token 将存储在用户的钱包中。
2. 没有余额显示问题。
3. 优雅的去中心化解决方案。

缺点：

1. 用户体验：购买者需要了解Token 归属 的概念和兑换过程。良好的文档、指南和用户友好的界面是必要的。
2. pull 方法用于付款，这意味着受益人需要执行两笔交易：购买和申领。
3. 尽管持有份额 Token 作为所有权，但用户除了将它们交换为目标 Token 之外，无法对它们执行任何操作。任何交易都会失败。
4. 主要缺点是实现此类系统的高度复杂性，这并不总是必要的。

3. 在单独的智能合约上进行 Vesting

在加密货币项目中实施 归属 的最流行方法是在单独的智能合约上放置 归属 逻辑。 在这种方法中，有很多变体，但我将介绍我们在一个实际项目中尝试过的一种。 主要思想来自以前的方法，但实现方式却大不相同。

重要的是要介绍两个概念以避免混淆：

1. 基础 Token — 这是用户购买并需要 归属 的主要项目 Token 或目标 Token。
2. 份额 Token — 这是一个虚拟 Token，发行给用户作为凭证，他们需要兑换该凭证才能以 1:1 的比率申领基础 Token。

我们的 归属 实施是几个智能合约的组合：

• 基础 Token 的私募智能合约
• 份额 Token 智能合约（带有 归属 逻辑）
• 用于创建具有设定计划的份额 Token 的智能合约

私募合约：它的主要任务是按照白名单销售 Token。此外，它还管理销售参数和付款收据。然而，在这种情况下，对我们来说最重要的是处理份额 Token 向购买者的发行。这里的关键在于，在销售期间，购买的 Token 不会转移给用户，而是转移给份额 Token 智能合约，在那里它们会被锁定。份额 Token 作为回报为用户铸造。我不会在此处提供此类智能合约的示例，因为基本上它可以是一个普通的 EOA。只需要授予基础 Token 对份额 Token 的批准，之后就可以将其铸造。

将来，用户将能够从此合约申领基础 Token，但他们需要销毁他们的份额 Token，这可以根据设定的 归属 时间表完成。

重要的是要提到只设置销售的开始时间，而结束时间将是 归属 的开始时间，这已在份额-Token 合约中确定。虽然销售的开始时间仍然可以更改，以及一些其他销售参数，但结束时间无法更改。这样做是为了保护用户免受操纵。他们的资金将被锁定，只有用户自己才能通过销毁他们的份额 Token 来提取资金。此外，在 归属 本身开始之前，可以在几个销售回合中使用相同的份额-Token。

份额 Token 合约：或者 归属 Token。它可以有任何名称。最重要的是要理解它的本质：它是一个虚拟 Token。它不能被出售或转移到另一个钱包。禁止转移此 Token，并且没有对其的管理控制。它有四个主要任务：

• 铸造
• 销毁
• 持有基础 Token
• 计算锁定和解锁的基础 Token 的数量

这里的铸造者是私募合约（请记住，这可以是具有基础 Token 的任何地址）。用户在申领他们的基础 Token 时将销毁这些 Token。没有人可以轻松地从合约中提取 Token；它充当一个安全的保险库。

下面是一个名为 VestingToken 的智能合约的简单示例。

这种方法允许为不同的销售回合创建多个份额 Token。每个份额 Token 将有自己的 归属 时间表。此外，它将充当销售回合的基础 Token 的池。这种方法给了我们比最初想象的更多的灵活性，但稍后会详细介绍。

该合约实现了一个非常灵活的设定 归属 时间表的功能。你可以将日期和时间指定为常规时间戳（精确到秒），设置任意数量的具有不同间隔的支付周期，甚至可以调整每个间隔的支付百分比。唯一的条件是总数加起来为 100%。这允许各种场景和 归属 分布图。下面是一个可以设置的时间表的示例。这表示 2 年的 归属 期，6 个月的 cliff period 和一个变化的百分比分布（最后两个月为 10%，所有先前月份为 5%）：

这是它在图表上的样子：

归属 计划

用于创建份额 Token 的智能合约：在我们的系统中，它被称为 Vesting Manager。从本质上讲，它是份额 Token 的工厂，它在底层与来自 OpenZeppelin 的 Minimal Clones 代理模式一起工作。在创建新 Token 时，除了 name 和 symbol 之外，还设置了时间表、基础 Token 地址和铸造者的地址。该合约能够更改份额 Token 的实现。

你还可以查看一个名为 VestingManager 的简单示例智能合约。

结果：

与其他选项相比，此方法也有其优点和缺点，但它实现了安全性、灵活性和开发速度之间的最佳平衡。此解决方案可以自信地称为去中心化且对用户透明，因为丢失资金的唯一方法是失去对其钱包的访问权限。还实施了各种机制来防止在配置销售回合或 归属 时间表时出现管理错误，但那是另一回事了。

结论

现在，为什么最后一个解决方案非常灵活？在初创公司中，一切都变化非常快，不可能完全对冲它，但你可以尝试做好准备。在我们的案例中，客户决定从根本上改变最初的概念。首先，后端主要负责销售，其次，现在需要在任何时候销毁份额 Token 并将其交换为 NFT。所有这些都与 归属 时间表断开了连接。此外，还需要销毁基础 Token。

销毁功能导致了许多复杂的任务，例如创建销毁回合和重新计算 归属 时间表。然而，负责 归属 的主要合约（份额 Token）已经为通过后端进行的销售做好了准备。只需要通过 Vesting Manager 合约创建它，并使用某个时间表进行设置，并将后端地址分配为铸造者。

所有这些都证实了本文的主要思想。对于 归属，没有标准、典型解决方案或基准。最有可能的是，它将始终是一个定制的解决方案，根据客户的特定需求量身定制，并结合来自其他项目的方法和定制发明。

非常感谢你阅读此材料。你还可以参与开发此材料和其他材料，并在我们的 GitHub 存储库 中贡献你的建议，我们将不胜感激 :)

• 原文链接： blog.blockmagnates.com/v...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～