> For the complete documentation index, see [llms.txt](https://web3-growth-agent-wga.gitbook.io/whitepaper_ver2.0_en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://web3-growth-agent-wga.gitbook.io/whitepaper_ver2.0_en/.-tokenomics-and-incentive-architecture/1.-token-system-overview.md).

# 1. Token System Overview

The WGA token structure does not originate from a reward design intended to incentivize participation.

WGA prioritizes the establishment of standardized criteria: determining which behaviors are eligible for analysis, identifying logs that must be excluded, and ensuring that these judgments remain reproducible over time. Without fixed standards, the accumulation of data does not lead to the accumulation of institutional trust.

WGA does not introduce a novel form of data. It addresses user behavioral data that is already utilized daily within the market.\
Enterprises modify products based on conversion and retention rates, and marketing departments allocate budgets based on behavioral data. The core issue is not the data itself, but the criteria by which that data is structured. While outputs are abundant, the processes used to generate them are often undocumented. This leads to conflicting conclusions from identical metrics and prevents data from being reproduced with the same significance over time.

WGA does not seek to solve this problem through tokenization alone. Instead, WGA establishes a framework for verification and recording. The token exists to link the verification outputs of this framework into a settleable unit within the network. In this model, the token does not create value; rather, settlement becomes possible only after the value has been defined and fixed.<br>

#### 1) Usage → Proof → Settlement

&#x20;The operational sequence of WGA remains constant: Usage.

* Usage: Actual behavioral events occur within Web2 or Web3 environments.&#x20;
* Validation: Artificial, redundant, or automated entries are isolated, and behaviors are normalized into meaningful units.&#x20;
* Proof: Verification results are structured and recorded in a standardized format.&#x20;
* Settlement: Financial or operational settlement is executed based on the provided Proof.

In this framework, the token is not a prerequisite for usage. Usage and verification can occur independently of the token. However, a common unit is required for multiple parties to settle verification results in a uniform manner and to ensure that settlement history is feedback-tracked. In WGA, the token functions as this common unit.

This settlement unit operates in direct alignment with verification standards at the protocol level. If verification results change, settlement conditions are updated automatically, and the settlement history is recorded alongside the corresponding verification version. The use of external currencies would decouple this link, necessitating manual adjustments between verification and settlement. WGA utilizes the token to internalize and minimize these adjustment costs at the protocol level.

#### 2) Two-layer Structure

WGA functionally separates its architecture into two distinct layers.

* Validation & Metric Layer: The segment where data collection, normalization, verification, and metric structuring are executed.
* Settlement & Economic Layer: The segment where settlement and feedback loops are executed based on Proof.

This separation facilitates two simultaneous capabilities.

* First, operational compatibility with Web2 environments. Usage can occur, verification can proceed, and Proof can be generated even in the absence of a digital wallet.&#x20;
* Second, the dependency of the settlement layer on data quality. Events that fail the verification process do not proceed to settlement. Settlement is executed exclusively based on Proof.

#### &#x20;3) Two Tokens, Two Roles

WGA bifurcates its operational units based on specific roles.

* XYZ: The circulating unit responsible for settlement and usage within the network.
* XYZD: An internal unit representing that verified behavior has been structured into Proof.

XYZD is not intended for circulation. XYZD is non-transferable and non-tradable. It serves as an internal network unit to record the fact that verified behavioral data has met specific criteria.

XYZ is the circulating unit that facilitates settlement and network usage based on these records.

XYZD is not directly convertible into XYZ. Instead, a reward budget allocation logic exists between the two. Budgets are allocated based on the quality distribution of Proof generated during specific periods, and the results are transitioned into a settleable state. The execution of settlement is at the discretion of the user.

#### &#x20;4) Proof Recording Principles&#x20;

WGA does not aim to record all granular data on-chain. The objective is to ensure that verification results are fixed in an immutable manner and that their integrity can be re-verified whenever necessary.

Accordingly, WGA adheres to the following principles

* Detailed event data is encrypted and managed off-chain.
* Verification results are structured in batch units.&#x20;
* Integrity fingerprints of batch results are fixed in a manner that allows for external verification.

The critical factor in this structure is not the storage location, but the assurance that verification results cannot be arbitrarily altered and that this integrity can be externally validated.

The data recorded on-chain consists of hash values of verification batches rather than individual events. Original data and verification process logs are maintained off-chain. If required, it can be proven that specific data was included in a particular batch. This methodology simultaneously satisfies integrity verification, cost efficiency, and privacy protection.

#### 5) Accrual and Settlement

WGA decouples the accumulation of verification results from actual settlement.&#x20;

* Usage records that pass verification can be accumulated, and settlement occurs when the accumulation meets certain conditions.
* Settlement occurs based on user selection or policy conditions.
* Accumulated records are attributed to the user's account.
* Usage records that pass verification may accumulate.&#x20;
* Settlement is executed when the accumulation meets specific conditions.&#x20;
* The execution of settlement is triggered by user choice or predefined policy conditions.&#x20;
* Accumulated records are attributed to the user account.

Users may convert these into settlement, except in cases where violations of terms or fraudulent activities are confirmed.&#x20;

Expiration conditions, if applicable, are disclosed in advance; however, verification records themselves are preserved for auditing purposes even after expiration.

This separation is a mechanism designed to maintain a Web2 user experience while structurally managing circulation velocity and settlement conditions.

#### 6) Claim Cost Policy

&#x20;The execution of settlement incurs network costs.

The default structure requires the user to bear these costs. However, options may be designed for partners or campaign entities to cover costs under specific circumstances. These options are not provided without limit; they are managed by policy conditions such as accumulation requirements, trust thresholds, and budget caps.

Regardless of the party bearing the cost, the settlement execution conditions remains identical. Regardless of who provides the fees, settlement is only possible for Proof that has passed the uniform verification standards.\ <br>