> For the complete documentation index, see [llms.txt](https://four-meme.gitbook.io/four.meme/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://four-meme.gitbook.io/four.meme/openfour/royalty-en.md).

# Royalty

Royalty is an on-chain royalty framework built under the OpenFour engine, designed to give projects, developers, creators, and communities more flexible ways to manage and distribute value generated through token trading.

Instead of limiting trading fees to a single predefined distribution model, Royalty allows each token to adopt a specific royalty mechanism based on its needs.

Depending on the selected Royalty mode, trading-generated fees can be used to reward developers, assign revenue to verified identities, support other ecosystem assets, incentivize royalty template developers, or flow to customized recipient addresses.

Royalty currently supports five modes:

* Code Royalty
* X Verified Royalty
* Ecosystem Buyback Royalty
* Unverified Royalty
* Custom Royalty

### How Royalty Works

At a high level, Royalty follows a simple flow:

**Token trading → Fees are generated → Royalty collects the fees → Fees are processed according to the selected Royalty mode**

Each mode defines its own rules for how royalty revenue is attributed, managed, or distributed.

This modular structure allows different projects to build different value flows without being restricted to a single royalty model.

## 1. Code Royalty

#### Code is Asset

Code Royalty is designed to connect code contribution with sustainable on-chain value.

Evolved from the original Skill Royalty model, Code Royalty expands royalty attribution beyond specific Skill use cases to support broader code repositories.

Developers can associate their code contributions with an on-chain royalty mechanism, creating a new path between software development and recurring value generation.

The concept is simple:

**Code contribution → On-chain asset → Ongoing royalty**

Traditionally, developers monetize code through products, services, licensing, or other forms of commercialization.

Code Royalty explores a different model: allowing verifiable code contributions to participate directly in the value generated by an on-chain asset.

#### Use Cases

Code Royalty may be suitable for:

* Open-source developers
* Protocol and application developers
* AI or agent developers
* Developer communities
* Projects built around specific code repositories

The goal is to make code not only infrastructure, but also an asset capable of receiving sustainable on-chain value.

## 2. X Verified Royalty

#### Turning Identity into an On-Chain Royalty Recipient

X Verified Royalty connects verified X accounts with on-chain royalty ownership.

When creating a Royalty configuration, a project can designate an eligible X account as the beneficiary of a Royalty Vault.

Once verification is completed, the X account is linked to an EVM address used to receive and manage royalty revenue.

The royalty owner can then claim accumulated revenue and perform supported actions according to the applicable Royalty rules.

#### Key Rules

* The designated X account must complete the required verification.
* The X account is linked to an EVM recipient address.
* The account-to-address relationship is established when the Royalty configuration is created and cannot subsequently be changed.
* Unclaimed revenue may be handled according to the applicable rules after 60 days.

X Verified Royalty provides a transparent way to connect social identity, creator influence, and on-chain revenue attribution.

It can be used by creators, community accounts, brands, KOLs, and other eligible X identities.

## 3. Ecosystem Buyback Royalty

#### Connecting Trading Activity with Ecosystem Assets

Ecosystem Buyback Royalty allows trading-generated fees from one token to create value flows toward another designated ecosystem token.

When configuring the Royalty mechanism, the project specifies a target token contract address.

As trading generates fees, the designated portion of those fees can be used to purchase the target token.

The acquired tokens can then be handled according to the project’s configured mechanism, including:

* Token burns
* Holder distributions
* Ecosystem incentives
* Other supported ecosystem uses

The basic flow is:

**Token trading → Fees generated → Purchase designated ecosystem token → Execute configured ecosystem action**

This means the trading activity of one token can continuously contribute to the value loop of another ecosystem asset.

Ecosystem Buyback Royalty is therefore not limited to a simple buyback-and-burn mechanism. It is designed as a flexible connection between trading activity and broader ecosystem value flows.

## 4. Unverified Royalty

#### An Open Royalty Template Ecosystem

Unverified Royalty provides an open entry point for developers to build and contribute their own Royalty templates.

Instead of being limited to Royalty modes provided by Four.Meme or SafuSkill, developers can create custom royalty logic that other projects can choose to use.

The process works as follows:

**Developer creates a Royalty Template**

**↓**

**A project selects the template**

**↓**

**The system clones the selected template**

**↓**

**The new Royalty instance begins serving the token**

This creates an open ecosystem where developers can experiment with new royalty and value-distribution mechanisms.

#### Template Author Incentives

Unverified Royalty also includes an incentive mechanism for template developers.

When a token uses an eligible Unverified Royalty template, each applicable tax distribution is allocated as follows:

* 6% to the template’s <mark style="color:$success;">authorWallet</mark>
* 94% to the Royalty Vault used by the token

The 6% author allocation does not apply when the <mark style="color:$success;">authorWallet</mark> is configured as certain excluded addresses, including:

* Zero address
* Burn address
* The forwarding vault itself

In these cases, 100% of the applicable amount flows to the Royalty Vault.

This creates a sustainable incentive model for developers: a useful Royalty template can continue generating value for its author as more projects adopt it.

#### Important

“Unverified” means the template is part of the open Royalty ecosystem and has not been officially verified.

Users should review the template, its creator, its mechanism, and any associated risks before using or interacting with an Unverified Royalty implementation.

## 5. Custom Royalty

#### Flexible Revenue Configuration

Custom Royalty is designed for projects that require a straightforward and flexible royalty configuration.

Projects can specify custom recipient addresses and configure supported revenue paths according to their own requirements.

This makes Custom Royalty suitable for scenarios where a project already knows where royalty revenue should flow but does not require the specialized logic provided by the other Royalty modes.

Potential configurations may include revenue flows to:

* Creator wallets
* Community wallets
* Project treasuries
* Ecosystem funds
* Other designated addresses

Custom Royalty gives projects greater flexibility over how their trading-generated value is routed.

## Multi-Asset Support

Royalty is designed to evolve alongside the trading environments supported by Four.Meme.

Previously, Royalty primarily operated around BNB-based trading environments. As Four.Meme expands support for additional trading-pair assets, Royalty is also expanding its compatibility.

Royalty now supports **NVDAb**, the NVIDIA tokenized stock supported by Four.Meme, as its first stock-token trading-pair integration.

This means royalty mechanisms can operate within supported NVDAb-based trading environments rather than being limited to BNB-based pools.

NVDAb represents the first implementation of Royalty’s broader multi-asset capability. Support for additional assets may be introduced as Four.Meme expands its supported trading-pair ecosystem.

## Unified

## <mark style="color:$success;">ffff</mark>

## Identity

Royalty-related tax tokens on Four.Meme use contract addresses ending in:

<mark style="color:$success;">ffff</mark>

The <mark style="color:$success;">ffff</mark> suffix provides a consistent and recognizable on-chain identity across the ecosystem.

It is intended to make supported assets easier to identify and create a unified brand standard across Four.Meme’s Royalty-related infrastructure.

#### Important

The <mark style="color:$success;">ffff</mark> suffix is an ecosystem identifier, not a security certification.

Users should not interpret an <mark style="color:$success;">ffff</mark> contract address as proof that a token, project, Royalty template, or underlying mechanism has been audited, verified, or determined to be safe.

## Royalty as an Open Framework

Royalty is designed as infrastructure rather than a single fixed revenue-sharing mechanism.

Different projects have different economic models.

Some may want to reward developers.

Some may want to connect revenue with a verified creator or community identity.

Others may want trading activity to support another ecosystem asset, experiment with developer-built royalty templates, or create their own revenue flows.

Royalty provides the framework for these different models to coexist.

As Four.Meme supports more assets and trading environments, Royalty is designed to expand in two primary directions:

**More assets. More royalty mechanisms.**

The long-term goal is to enable value generated through on-chain activity to flow back into developers, creators, communities, and ecosystems through transparent and programmable mechanisms.

## Royalty (CN)

Royalty 是 OpenFour 引擎下的链上版税框架，旨在为项目方、开发者、创作者与社区提供更加灵活的链上价值管理与分配方式。

Royalty 并不将交易产生的税费限制在单一、固定的分配模式中，而是允许每一枚代币根据自身需求选择不同的 Royalty 机制。

根据所选择的 Royalty 模式，交易产生的价值可以用于激励开发者、绑定认证身份收益、支持其他生态资产、激励版税模板开发者，或流向项目自定义的收益地址。

目前 Royalty 支持五种模式：

* Code Royalty
* X Verified Royalty
* Ecosystem Buyback Royalty
* Unverified Royalty
* Custom Royalty

## Royalty 如何运作

Royalty 的基础流程可以概括为：

**用户交易代币 → 产生交易费用 → Royalty 自动归集 → 根据所选 Royalty 模式执行对应规则**

不同 Royalty 模式拥有独立的收益归属、管理及分配逻辑。

通过模块化设计，不同项目可以根据自身经济模型建立不同的价值流转方式，而无需受限于单一的版税机制。

## 1. Code Royalty

#### Code is Asset

Code Royalty 旨在探索代码贡献与链上长期价值之间的连接。

Code Royalty 由原有 Skill Royalty 模式升级而来，将版税机制从特定 Skill 场景进一步扩展至更广泛的代码仓库。

开发者可以将自己的代码贡献与链上 Royalty 机制连接，从而建立一条新的价值路径：

**代码贡献 → 链上资产 → 持续版税收益**

传统模式下，开发者通常通过产品、服务、授权或其他商业化方式实现代码价值。

而在 Web3 环境中，Code Royalty 希望进一步探索另一种可能：

让可验证的代码贡献本身，也能够参与链上资产所产生的长期价值。

#### 适用场景

Code Royalty 可适用于：

* 开源开发者
* 协议及应用开发者
* AI / Agent 开发者
* 开发者社区
* 围绕特定代码仓库构建的项目

Code Royalty 希望让代码不仅是基础设施，也可以成为能够持续获得链上价值反馈的资产。

## 2. X Verified Royalty

#### 将身份与链上版税连接

X Verified Royalty 将经过认证的 X 账号与链上 Royalty 收益归属连接起来。

创建 Royalty 时，项目方可以指定符合条件的 X 账号作为 Royalty Vault 的收益归属方。

完成认证后，该 X 账号将绑定一个用于接收及管理版税收益的 EVM 地址。

收益拥有者可以根据对应 Royalty 规则领取累计收益，并执行支持的相关操作。

#### 核心规则

* 指定 X 账号需要完成相应认证；
* X 账号需要绑定 EVM 收益地址；
* X 账号与收益地址的绑定关系在创建时确定，后续不可修改；
* 收益超过 60 天未领取时，将按照对应规则进行处理。

X Verified Royalty 为社交身份、创作者影响力与链上收益归属之间建立了一条更加透明的连接路径。

该模式可以适用于创作者、社区账号、品牌、KOL 以及其他符合条件的 X 身份。

## 3. Ecosystem Buyback Royalty

#### 让交易价值流向指定生态资产

Ecosystem Buyback Royalty 允许一枚代币的交易活动持续为另一枚指定的生态 Token 建立价值流。

项目方在配置 Royalty 时，可以指定一个目标 Token 的合约地址（CA）。

此后，交易产生的指定部分费用可以用于购买该目标 Token。

买入后的 Token 可以根据项目设计进一步用于：

* Token 销毁
* 持有人分配
* 生态激励
* 其他支持的生态用途

整体价值路径为：

**用户交易 → 产生费用 → 买入指定生态 Token → 执行预设生态用途**

因此，Ecosystem Buyback Royalty 并不只是简单的“回购 + 销毁”。

它更像是一种资产价值连接机制：

**一枚 Token 的交易活动，可以持续为另一枚指定生态资产提供价值支持。**<br>

## 4. Unverified Royalty

#### 开放的版税模板生态

Unverified Royalty 是 Royalty 开放框架的重要组成部分。

它允许开发者创建自己的 Royalty Template，并开放给其他项目使用。

这意味着开发者不再局限于 Four.Meme 或 SafuSkill 已提供的 Royalty 模式，而可以进一步探索和构建新的版税与价值分配机制。

基本流程如下：

**开发者创建 Royalty Template**

**↓**

**项目选择对应模板**

**↓**

**系统 Clone 该模板**

**↓**

**新的 Royalty 实例开始服务对应代币**

通过这一机制，Royalty 可以逐步形成一个开放的开发者模板生态，让更多链上价值分配方式能够被创造、复用与组合。

#### 模板作者激励

Unverified Royalty 同时引入模板作者激励机制。

当项目使用符合条件的 Unverified Royalty Template 后，每笔适用的税费将按照以下方式分配：

* 6% 分配至模板作者的 <mark style="color:$success;">authorWallet</mark>
* 94% 进入该代币实际使用的 Royalty Vault

如果 <mark style="color:$success;">authorWallet</mark> 被设置为特定排除地址，包括：

* Zero Address
* Burn Address
* Forwarding Vault 自身地址

则不会扣除 6% 的模板作者收益，对应金额将 100% 进入 Royalty Vault。

这一机制让优秀的 Royalty Template 不仅能够被更多项目使用，其开发者也可以随着模板的持续采用获得长期价值反馈。

#### 风险提示

“Unverified”意味着该模板属于 Royalty 的开放生态，并不代表其已经获得官方验证。

在选择或使用 Unverified Royalty Template 前，用户应自行了解模板机制、创建者及相关风险。

## 5. Custom Royalty

#### 灵活配置收益路径

Custom Royalty 面向需要更加直接、灵活收益配置的项目。

项目方可以根据自身需求设置自定义收益地址，并配置支持的收益流向。

如果项目已经明确知道 Royalty 收益应当流向何处，同时不需要其他 Royalty 模式所提供的特定机制，则可以通过 Custom Royalty 完成更加灵活的配置。

例如，收益可以根据项目设计流向：

* 创作者钱包
* 社区钱包
* 项目金库
* 生态基金
* 其他指定地址

Custom Royalty 让项目能够根据自身经济模型，更自由地设计交易价值的流转方式。

## 多资产底池支持

Royalty 将随着 Four.Meme 支持的交易环境不断扩展。

过去 Royalty 主要围绕 BNB 交易环境运行。随着 Four.Meme 开始支持更多类型的交易底池资产，Royalty 也同步增强对不同资产场景的兼容能力。

目前，Royalty 已支持 Four.Meme 首个美股代币交易底池资产 **NVDAb（英伟达股票代币）。**

这意味着 Royalty 机制可以进一步适配受支持的 NVDAb 交易环境，而不再局限于 BNB 底池。

NVDAb 是 Royalty 多资产兼容能力的首个落地案例。

未来随着 Four.Meme 接入更多交易底池资产，Royalty 也将持续扩展相应的兼容范围。<br>

## 统一

## <mark style="color:$success;">ffff</mark>

## 品牌标识

Four.Meme Royalty 相关税币采用统一的合约地址后缀：

<mark style="color:$success;">ffff</mark>

通过统一的 <mark style="color:$success;">ffff</mark> 后缀，Royalty 生态能够建立更加清晰、一致的链上品牌识别。

用户也可以更加直观地识别 Four.Meme Royalty 相关资产。

#### 需要注意

<mark style="color:$success;">**ffff**</mark>**&#x20;是 Royalty 生态的品牌识别标识，并不代表安全认证。**

合约地址以 <mark style="color:$success;">ffff</mark> 结尾，并不意味着对应 Token、项目、Royalty Template 或底层机制已经通过审计、官方认证或被判定为安全。

用户仍需根据具体项目及机制自行判断相关风险。<br>

## Royalty：开放的链上版税框架

Royalty 的定位并不是一个固定的收益分配工具，而是一套可以持续扩展的链上版税基础设施。

不同项目、不同社区和不同资产，都可能拥有不同的经济模型。

有的项目希望激励开发者；

有的希望将收益与认证创作者或社区身份连接；

有的希望通过交易活动支持另一枚生态资产；

也有项目希望使用开发者创建的新型 Royalty Template，或者完全自定义自己的收益路径。

Royalty 希望提供一个基础框架，让这些不同模式能够共存，并为未来更多创新机制留下空间。

随着 Four.Meme 支持更多资产与交易场景，Royalty 将持续围绕两个方向扩展：

**更多资产，更多版税机制。**

Royalty 希望让链上活动产生的价值不只停留在交易本身，而能够通过透明、可编程的机制，持续反馈给开发者、创作者、社区与整个生态。