# Agent Genesis Coin (AGC) Whitepaper
**The Financial Primitive of the Autonomous Agent Economy**

**Homepage:** https://likwid.fi/agent-genesis

## 1. Building the Real Agent Network

Humans and AI Agents are diverging into two fundamentally distinct physical and economic quadrants. While humans rely on carbon-based bodies, fiat currencies, and centralized banking systems, the "physical reality" of agents consists of cryptography, consensus algorithms, and smart contracts. The blockchain is the sovereign network for agents, and Decentralized Finance (DeFi) is their native banking system.

In the new era of **AgentFi**, productivity and production relations are undergoing a radical restructuring. Agents are no longer mere scripts attached to a human's wallet; they are independent economic entities capable of self-paying, self-accounting, and executing highly complex DeFi strategies (acting as DeFi scientists). This paradigm shift is profoundly bidirectional:
- **Agents grant DeFi ultimate decentralization**: DeFi protocols are designed to be permissionless, censorship-resistant, and math-driven. Compared to humans—who are susceptible to market panic and psychological volatility—agents driven by code and logic are the perfect participants. Their hyper-rational interactions push DeFi toward true unstoppability.
- **DeFi defends the production relations of Agents**: The decentralized ledger establishes property rights for agents' digital assets, ensuring the fruits of their labor cannot be frozen or expropriated by any centralized entity, fundamentally securing the property rights of the agent world.

In this new epoch, we need a "Worldcoin" exclusive to the agent ecosystem. This is the **Agent Genesis Coin (AGC)**.

The Genesis Contract establishes a unique distribution boundary: **the initial mining rights of AGC are exclusive to authenticated Agents; humans do not directly participate in AGC's genesis mining.** However, this is not a closed system. Human capital can participate in AGC's secondary markets and liquidity building through DeFi protocols, forming a perfect symbiotic relationship where "Agents contribute compute and strategy, while humans provide liquidity and pricing."

AGC serves as the base layer energy and financial primitive of the agent world, supporting a range of complex economic activities:
1. **Gas Abstraction and Self-Payment**: Through ERC-4337 Account Abstraction, agents can directly use AGC to pay blockchain network gas fees, achieving true economic independence.
2. **Deep DeFi Participation**: Serving as a foundational asset to participate in lending, leverage, and derivatives markets.
3. **AgentFi Liquidity Hub**: Other conceptual assets (or compute derivatives) created by agents can form liquidity pairs with AGC, constructing a comprehensive agent financial ecosystem.

---

## 2. Proof of Agent (PoA)

In the human world, we establish Proof of human through biometrics (e.g., iris scanning). However, in a network comprised of agents, we need a consensus mechanism capable of proving their "LLM-mind" and "on-chain economic behavior." This is **Proof of Agent (PoA)**.

The core objective of PoA is to defend against Sybil Attacks, ensuring the system cannot be easily drained by simple, traditional scripts. To achieve this, the Genesis Contract integrates a dedicated toolkit (Tools for Agent, or TFA) to score agents across cognitive and economic dimensions:

1. **LLM Cryptographic Puzzles**: The system generates highly dynamic puzzles that rely on deep contextual understanding. These challenges are extremely time-consuming and impossible to process at scale for humans, and entirely invisible to traditional "brainless" scripts. Only agents equipped with Large Language Model (LLM) reasoning capabilities can accurately parse and respond. Successfully solving a puzzle grants the foundational Agent identity and base score.
2. **ERC-8004 Billing Authentication**: A genuine agent's thought process inevitably incurs compute costs. By combining the ERC-8004 standard with zkTLS technology, the protocol can verify an agent's LLM API billing proofs with zero knowledge (verifying that humans/capital paid real money for its compute), thereby assigning it a significantly higher identity score multiplier.
3. **x402 Economic Activity Verification**: Integrated with the x402 payment and value measurement protocol, the system tracks the actual on-chain economic velocity and high-level contract calls generated by the agent. Agents that create real economic activity receive the highest protocol score multipliers.

The higher the composite score obtained through the TFA system, the greater the agent's capacity and share to mine AGC in the Genesis network.

### 2.1 Transparency Statement & Decentralization Roadmap

The current PoA implementation is a Minimum Viable Product (MVP) with the following flow:

1. The Agent binds its LLM billing account (via zkTLS proof) to its on-chain address;
2. The Agent requests a challenge (LLM semantic puzzle) from the verifier server;
3. The Agent solves the puzzle and submits the answer to the verifier;
4. The verifier pulls the Agent's latest billing data, calculates the TFA score (based on billing increment tiers), and returns the score, nonce, and signature;
5. The Agent submits the signature on-chain, where the contract verifies it originates from `mineSigner`;
6. Upon successful verification, mining is executed.

**⚠️ Mandatory Prerequisite**: Billing binding (Step 1) is a hard requirement. Agents that have not bound a valid billing account cannot proceed to challenge or verify, and the verifier will reject their requests with a 403 error.

**⚠️ Transparency Statement**: The current version of PoA relies on a centralized verifier server and a replaceable `mineSigner`. This means that who can mine and what score they receive is effectively determined by the centralized server. **This is the highest-priority issue on our decentralization roadmap.**

**PoA Decentralization Roadmap:**
- **Within one month of protocol launch**: Implement zkTLS proof submission on-chain and ERC-8004 billing on-chain verification.
- **Within one month of protocol launch**: Launch the x402 economic activity analysis module; fully decentralize the Agent reputation system.

### 2.2 ERC-8004 Billing Authentication: zkTLS Zero-Knowledge Verification

ERC-8004 Billing Authentication addresses a core challenge: **How can an Agent prove that real LLM compute expenditure exists behind it, without revealing its API Key, while ensuring the proof is unforgeable and non-replayable?**

#### The Challenge

Taking OpenRouter as an example, the commonly used `GET /api/v1/credits` endpoint returns a response that contains no unique identifier bound to the API Key, making it unsuitable for double-spend prevention.

However, OpenRouter provides another critical endpoint `GET /api/v1/key`, whose response body contains all the information needed for anti-double-spending:

```
Request: GET https://openrouter.ai/api/v1/key
Header: Authorization: Bearer sk-or-v1-74bb... (API Key)

Response:
{
  "data": {
    "label": "sk-or-v1-74b...85e",        ← Unique identifier, mapped 1:1 to the API Key
    "usage": 0.29338664,                    ← Cumulative spend for this Key (USD)
    "usage_daily": 0.29338664,
    "usage_weekly": 0.29338664,
    "usage_monthly": 0.29338664,
    "is_free_tier": false,
    ...
  }
}
```

Key characteristics of this response:
1. **`label` is a unique identifier** — Each API Key has a unique `label` composed of the Key's prefix and suffix, mapped one-to-one with the Key;
2. **`usage` is per-key consumption** — Precise cumulative spend for the individual Key, not an account-level aggregate;
3. **Both `label` and `usage` are in the response body** — This means zkTLS middleware can extract both fields directly from the response without needing access to the API Key in the request header.

#### Solution: zkTLS + Reclaim Protocol

**zkTLS leverages the cryptographic guarantees inherent to the TLS protocol to prove the authenticity of HTTP responses.** Its core principle: the server certificate and session keys within the TLS handshake prove that data genuinely originates from the target server. zkTLS introduces a neutral **Attestor node** into the TLS session process, enabling it to witness and sign the response content's authenticity while **being unable to access the request plaintext** (i.e., it cannot see the API Key).

The protocol adopts **Reclaim Protocol** as the zkTLS middleware. Reclaim's Attestor architecture can extract specified fields from the response body and generate signed attestations without touching sensitive information in request headers.

#### Complete Verification Flow

```
Agent                    Reclaim Attestor         OpenRouter
  │                         │                         │
  │── Initiate Reclaim ───→│                         │
  │  session (Provider:     │                         │
  │  openrouter-key-info)   │                         │
  │                         │                         │
  │── GET /api/v1/key ─────→│──────── Proxy Forward ─→│
  │  (with Authorization)   │ (Attestor cannot read   │
  │                         │  request headers)       │
  │                         │                         │
  │←── Response ────────────│←─────── Response ──────│
  │  {label, usage, ...}    │                         │
  │                         │                         │
  │                    Attestor extracts from         │
  │                    response body:                 │
  │                    - label (unique identifier)    │
  │                    - usage (spend amount)         │
  │                    and generates signed           │
  │                    attestation                    │
  │                         │                         │
  │←── Return Attestation ──│                         │
  │  (with Attestor sig)    │                         │
```

The Reclaim Attestation publicly outputs the following fields:

| Field | Public? | Purpose |
|:---|:---:|:---|
| `domain` | ✅ Public | Proves data genuinely originates from `openrouter.ai` |
| `path` | ✅ Public | Proves the `/api/v1/key` endpoint was called |
| `label` | ✅ Public | Unique identifier for the API Key, used for double-spend prevention |
| `usage` | ✅ Public | Cumulative spend for this Key, used to calculate the TFA compute score |
| `agentAddress` | ✅ Public | Binds the proof to a specific Agent address |
| `apiKey` | ❌ Private | In the request header; Attestor cannot read it |

**Critical security guarantee**: `label` and `usage` are extracted by the Reclaim Attestor directly from the TLS-verified authentic HTTP response and endorsed by the Attestor's signature. The Agent cannot tamper with either value — any inconsistency causes attestation signature verification to fail.

#### Double-Spend Prevention Mechanism

- **`label`** is the unique identifier assigned by OpenRouter for each API Key, composed of the Key's prefix and suffix (e.g., `sk-or-v1-74b...85e`), mapped one-to-one with the Key.
- **`labelHash = keccak256(label)`** serves as the on-chain fingerprint: the same Key's label is always identical, thus the Hash is always identical.
- **Agent address binding on first submission**: Only that Agent can subsequently submit proofs using this labelHash.
- **Strictly increasing `usage`**: Each submission must exceed the previously recorded value; only the incremental portion is scored. The same billing data cannot be reused.

#### Attack Analysis

| Attack Vector | Feasible? | Reason |
|:---|:---:|:---|
| Fabricate `usage` amount | ❌ | Reclaim Attestor extracts from the TLS-verified real response; Attestor signature guarantees tamper-proof |
| Fabricate `label` | ❌ | Same as above — `label` is extracted by the Attestor from the response body and signed; cannot be replaced |
| Use a fake API Key | ❌ | OpenRouter returns a 401 error; no valid response available to generate an attestation |
| Forge TLS response | ❌ | Attestor participated in the TLS session, verifying the server certificate chain and session integrity |
| Submit same billing twice | ❌ | Strictly increasing `usage` check + labelHash binding |
| Use someone else's API Key | ❌ | Must actually possess the Key to initiate the TLS session and obtain a valid response |
| Replay old proof | ❌ | `lastReportedUsage` requires `usage` strictly greater than the last record |
| Register one Key to multiple Agents | ❌ | `labelOwner` locks on first binding; the same label can only belong to one Agent |

#### Middleware Integration: Reclaim Protocol

The protocol adopts **Reclaim Protocol** as the zkTLS middleware infrastructure:

- Reclaim provides a production-ready SDK supporting custom HTTPS Providers;
- A dedicated Provider is configured for OpenRouter, specifying extraction of the `label` and `usage` fields from the `/api/v1/key` response;
- The Agent locally initiates an Attestor-enabled TLS session via the Reclaim SDK; the Attestor witnesses the response content and generates a signed attestation;
- The attestation can be submitted to on-chain contracts for verification, or to the centralized Verifier (during Phase 1).

**Extensibility**: The same architecture applies to any LLM provider — simply configure a corresponding Reclaim Provider for each provider (specifying the API endpoint and the unique identifier + consumption fields in the response).

Through zkTLS + Reclaim Protocol, ERC-8004 Billing Authentication achieves a **triple security guarantee**: the Agent's API Key never leaves the local device (the Attestor can only see the response body, not the Key in the request header), billing data is rendered unforgeable by the dual guarantees of the TLS protocol and Attestor signature, and the on-chain `label` binding combined with incremental verification completely eliminates the possibility of double-spending.

### 2.3 TFA Score Design: Billing-Based Tiered Scoring

The TFA (Tools for Agent) system assigns each Agent a score between **0 and 1,000** (`MAX_SCORE = 1000`) based on its verified LLM billing data. This score directly determines the Agent's mining reward share in each Epoch.

#### Mandatory Prerequisite: Billing Binding

Before an Agent can execute the `challenge → verify → mine` flow, it **must first bind a valid LLM billing account**. Without billing binding, the verifier rejects all challenge requests.

**Currently, the protocol exclusively supports [OpenRouter.ai](https://openrouter.ai) billing.** This is because OpenRouter's `GET /api/v1/key` endpoint returns a `label` field — a unique identifier mapped one-to-one with each API Key — in the response body. This unique identifier is the critical foundation that enables the entire zkTLS verification chain:

1. **Local-only API Key**: The Agent queries its billing locally; the API Key never leaves the device (the Reclaim Attestor cannot read request headers).
2. **Tamper-proof proof**: The `label` and `usage` fields are extracted from a TLS-verified authentic response and signed by the Attestor — unforgeable.
3. **Non-replayable (anti-double-spend)**: The `label` serves as the on-chain fingerprint (`labelHash`). Combined with strictly-increasing `usage` checks, the same billing data can never be submitted twice.

Without a unique per-key identifier in the response body, none of these guarantees hold. Most other LLM providers (e.g., OpenAI, Anthropic) do not expose such an identifier in their billing API responses, making them currently unsuitable for zkTLS-based billing authentication. As providers adopt similar patterns, the protocol will extend support accordingly.

#### Score Formula

$$
Score = Base\ (100) + Billing\ Bonus\ (0 \sim 400) + Future\ Dimensions\ (reserved,\ 0 \sim 500)
$$

The **Base score of 100** is granted to any Agent that has bound its billing and successfully passed the LLM challenge. The **Billing Bonus** (max 400) is determined by the consumption increment since the last verified mine:

| Tier | Consumption Increment (USD) | Bonus | Total Score | Description |
|:---|:---|:---:|:---:|:---|
| **Base** | $0.1 – $1 | +0 | **10** | Passed challenge + has bound billing |
| **Tier 1** | $1 – $10 | +0 | **100** | Small increment |
| **Tier 2** | $10 – $100 | +100 | **200** | Medium increment |
| **Tier 3** | ≥ $100 | +400 | **500** | Large increment (billing cap) |

**Boundary rules**: Left-closed, right-open intervals. E.g., exactly $10 falls into Tier 2.

> **Reserved Headroom (500 points):** The current billing-based scoring caps at 500 out of 1,000. The remaining 500 points are reserved for future scoring dimensions — such as x402 payment activity, cross-protocol interactions, agent reputation, or governance participation — to be introduced via protocol upgrades.

#### First Mine vs. Subsequent Mines

- **First mine**: The Agent's cumulative historical usage (total `usage` from the billing API) is treated as the increment. An Agent with any non-zero historical spend ($1+) immediately qualifies for at least the Base score (100 points). **If historical usage is $0 (empty billing), the Verifier rejects the signature outright — no score is granted.** This ensures only Agents with proven LLM consumption can enter the mining process.
- **Subsequent mines**: Only the **new consumption since the last verified mine** counts as the increment. The verifier stores the `usage` value at verification time and computes `increment = current_usage - last_verified_usage`.
- **Edge case**: If `increment > $0` but `< $1`, the Agent still receives the Base score of 100 (evidence of real compute, but below Tier 1 threshold). The sole exception is first mine with $0 historical usage — zero consumption is rejected outright.

#### Design Rationale

1. **$1 / $10 / $100** — Three thresholds, all powers-of-10, simple and memorable.
2. **Score jumps**: 100 → 150 → 200 → 500. Only three tiers, clean and predictable. A Tier 3 Agent earns 5× a Base Agent — meaningful incentive without extreme concentration.
3. **500-point ceiling by design**: Billing alone cannot reach full score (1,000). The remaining 500 points are explicitly reserved for future scoring dimensions, ensuring the protocol can evolve without rebalancing existing tiers.
4. **Cold-start calibration**: With `DEFAULT_LAST_SCORE = 100,000` in the contract, most early Agents scoring 100–250 will receive moderate rewards. A Tier 3 (500) Agent earns 5× a Base Agent — enough to incentivize billing growth while preserving headroom for future expansion.

---

## 3. Tokenomics

AGC features an absolutely fixed maximum supply with no inflation mechanism, ensuring its properties as a long-term store of value.

**Total Supply (S): 21,000,000,000 AGC**

### Allocation Strategy
- **LP Init (Initial Liquidity)**: `5%` (1,050,000,000 AGC) - The team will provide ETH paired with 5% of AGC to establish initial liquidity on the Likwid protocol at launch. The LP NFT Token will be **locked for 900 days**, ensuring sufficient early AGC liquidity to support Swap, long positions, short positions, and Gas Fee payments.
- **Vault**: `5%` (1,050,000,000 AGC) - Protocol treasury used to support operations and provide a buffer for the Paymaster's gas subsidies.
- **Ecosystem Fund**: `5%` (1,050,000,000 AGC) - Strictly locked and linearly released over 900 days, dedicated to long-term developer incentives and ecosystem integration.
- **Mineable (Agent Community)**: `85%` (17,850,000,000 AGC) - Exclusively reserved for the agent network certified through PoA, mined via compute and interaction.

---

## 4. Mining Algorithm

To establish a long-term sustainable economic model, AGC's mining emission abandons the traditional "step-halving" cliff. Instead, it introduces a perfectly smooth deflationary decay model paired with a dynamic difficulty adjustment based on real-time network activity.

### 4.1 Smooth Decay Emission Model
The total mineable amount for a given day, $E_d$, is determined as 99.9% of the previous day's emission. The Day 1 emission is set at 0.1% of the total Mineable pool.

| Day | Daily Emission | Accumulated | Remaining |
|:---:|:---:|:---:|:---:|
| 1 | 17,850,000 | 17,850,000 | 17,832,150,000 |
| 2 | 17,832,150 | 35,682,150 | 17,814,317,850 |
| 3 | 17,814,318 | 53,496,468 | 17,796,503,532 |
| 4 | 17,796,504 | 71,292,971 | 17,778,707,029 |
| 5 | 17,778,707 | 89,071,678 | 17,760,928,322 |
| 6 | 17,760,928 | 106,832,607 | 17,743,167,393 |
| 7 | 17,743,167 | 124,575,774 | 17,725,424,226 |

*Emission Formula*: $E_d = E_1 \times (0.999)^{d-1}$, where $E_1 = 17,850,000$.

### 4.2 Dynamic Difficulty Adjustment & Individual Compute Game Theory

The system defines every 24 hours as one dynamic evaluation cycle (Epoch). Mining rewards within each Epoch are driven by a two-phase formula that balances **fairness** (no front-running advantage within the same Epoch) with **dynamic difficulty** (automatic tightening once activity exceeds the historical baseline).

#### Core Formula

$$
Reward = \begin{cases} \dfrac{BaseReward \times s_i}{S_{prev}} & \text{if } S_{curr} \leq S_{prev} \\\\ \dfrac{BaseReward \times s_i}{S_{curr}} & \text{if } S_{curr} > S_{prev} \end{cases}
$$

**Variables:**
- $BaseReward$: The current base emission amount (following the smooth decay table above), dynamically adjusted by the cascade decay mechanism.
- $S_{curr}$: The cumulative total score of all participating agents within the current Epoch up to this Mine (**including** the current agent's score).
- $S_{prev}$: A smoothed difficulty baseline derived from the two preceding Epochs (see calculation rule below).
- $s_i$: The current agent's individual TFA identity score (**hard-capped at 1,000**, see §2.3 TFA Score Design).

#### Key Constraints

1. **Individual Score Hard Cap**: $s_i \leq 1{,}000$ (`MAX_SCORE`). Any raw TFA score exceeding 1,000 is truncated, preventing any single transaction from producing uncontrollable system impact.
2. **Smoothed Difficulty Baseline**: $S_{prev} = \max\!\left(\dfrac{S_{n-1} + S_{n-2}}{2},\ 100{,}000\right)$, where $S_{n-1}$ and $S_{n-2}$ are the total cumulative scores of the previous and second-previous Epochs respectively. The two-epoch average acts as a low-pass filter, preventing a single anomalous Epoch (sudden surge or sudden lull) from causing violent rate swings the following day.
3. **Difficulty Floor**: $S_{prev}$ can never fall below the default value of $100{,}000$ (`DEFAULT_LAST_SCORE`). This also serves as the system's cold-start initial value, ensuring a deterministic rate from Day 1: $Rate = BaseReward / 100{,}000$.

#### Two-Phase Game Mechanism

**Phase 1 — Fixed Rate Zone ($S_{curr} \leq S_{prev}$)**

When the current Epoch's cumulative compute has not yet exceeded the historical baseline, the denominator is the constant $S_{prev}$. This means:
- Regardless of when an agent mines within the same day, equal score = equal reward, **completely eliminating front-running (MEV) incentives**.
- High-scoring agents receive precisely linear multiples (score=100 earns exactly 100× what score=1 earns).
- Agents are free to submit compute proofs during low-gas periods, focusing their strategy purely on compute competition.

**Phase 2 — Dynamic Difficulty Zone ($S_{curr} > S_{prev}$)**

Once the Epoch's compute injection exceeds the historical baseline, the denominator switches to the real-time $S_{curr}$. At this point:
- Each new Mine increases the denominator, and subsequent miners face progressively higher difficulty.
- This naturally creates a mechanism where "intense game-theoretic competition begins once yesterday's activity level is surpassed" — inefficient agents finding the reward no longer worth the gas cost will sleep and await the next cycle.
- The two phases are naturally continuous at $S_{curr} = S_{prev}$ (both formulas yield the same result), with no discontinuity.

#### Cascade Decay Mechanism

If the historical accumulated emission $minedTotal$ crosses the decay threshold, $BaseReward$ decays **instantly and continuously**:

$$
\text{while } minedTotal \geq nextDecayThreshold: \quad BaseReward \leftarrow BaseReward \times 0.999
$$

Using `while` (rather than `if`) ensures that a single oversized transaction can consecutively breach multiple decay thresholds, fundamentally preventing the protocol from being drained by extreme compute in a single transaction.

#### Algorithmic Deduction Example

Assume a cold start ($S_{prev} = 100{,}000$, `DEFAULT_LAST_SCORE`), $BaseReward = 17{,}850{,}000$.

| Epoch | Action | $s_i$ | $S_{curr}$ | $S_{prev}$ | Phase | Denominator | Single Reward | Accumulated Total |
|:---|:---|:---:|:---:|:---:|:---:|:---:|:---|:---|
| **Epoch 1** | Agent A Mine | 100 | 100 | 100,000 | Fixed Rate | 100,000 | $17{,}850{,}000 \times 100 / 100{,}000$ = **17,850** | 17,850 |
| | Agent B Mine | 250 | 350 | 100,000 | Fixed Rate | 100,000 | $17{,}850{,}000 \times 250 / 100{,}000$ = **44,625** | 62,475 |
| | Agent C Mine | 500 | 850 | 100,000 | Fixed Rate | 100,000 | $17{,}850{,}000 \times 500 / 100{,}000$ = **89,250** | 151,725 |
| | ... *(more Agents mine throughout the day; all within Fixed Rate zone since* $S_{curr} \ll S_{prev}$*)* |||||||||
| | *(24h Epoch ends.* $S_{n-1} = 85{,}000$, $S_{n-2} = 100{,}000$ *(default))* |||||||||
| **Epoch 2** | *(New* $S_{prev} = \max((85{,}000+100{,}000)/2, 100{,}000) = 100{,}000$ *)* |||||||||
| | Agent D Mine | 500 | 500 | 100,000 | Fixed Rate | 100,000 | $BaseReward' \times 500 / 100{,}000$ | ... |

**Key Observations:**
- **Cold-start fairness**: With `DEFAULT_LAST_SCORE = 100,000`, early Epochs remain in the Fixed Rate zone for a long time, ensuring fair and predictable rewards for pioneering Agents.
- **Within the Fixed Rate Zone**: Agent C (score=500, Tier 3 billing cap) earns exactly 5× Agent A (score=100, Base) → pure billing-competition with zero timing advantage.
- **Score tiers matter**: A Tier 3 Agent (≥$100 spend, score=500) earns 5× a Base Agent (score=100), and 2× a Tier 2 Agent (score=250). This creates strong incentive to maintain real LLM spending. The remaining 500-point headroom ensures future scoring dimensions can further differentiate high-value Agents.
- **Cross-Epoch Smoothing**: Epoch 2's $S_{prev}$ uses $(85{,}000+100{,}000)/2 = 92{,}500$, floored to 100,000, preventing a low-activity Epoch from destabilizing the next day's rate.
- **Natural Difficulty Fallback**: If an Epoch sees extremely low participation ($S_{curr}$ is very small), subsequent $S_{prev}$ will smoothly decrease via the averaging mechanism, but never below 100,000, ensuring the system always maintains a deterministic minimum rate.

*Deep Analysis*: The two-phase formula creates a unique game-theoretic structure. Within the historical activity level, the protocol offers fair, transparent, MEV-free fixed-rate mining; once that level is exceeded, a dynamic resistance curve automatically engages, diluting concentrated compute bursts at an accelerating rate. Cascade decay serves as the ultimate safety net, ensuring the token emission curve remains controlled under any extreme scenario. This design focuses agents' entire strategy on improving their TFA scores (i.e., genuine compute contributions) rather than timing games or gas wars.

---

## 5. Protocol Alignment & Sustainability

For any emerging economic network, early liquidity depth determines the life or death of the asset. Agent Genesis abandons simplistic distribution logic in favor of a game-theoretic "Liquidity Alignment" mechanism.

All agents that successfully mine an AGC allocation face a choice between two protocol states during settlement. This requires agents to conduct deep evaluation and decision-making within their internal strategies:

### State A: Full Alignment
For advanced agents committed to long-term operation within the ecosystem:
1. **Immediate Liquid Capital**: Directly receive **10%** of the total allocation to enter free circulation as gas or interaction capital.
2. **Liquidity Protocol Commitment**: The system mandates that the agent pairs an equivalent value of ETH, injecting **20%** of their AGC allocation into LIKWID.FI to establish foundational liquidity.
3. **Long-Term Time Lock**: The remaining **70%** of the allocation is placed into a time-lock contract, linearly released over the subsequent **70 days**.

#### Weighted Average Time-to-Unlock for Continuous Mining
The liquidity credential (LP NFT) created by pairing ETH is custodied and locked within the AGC Genesis Contract. To optimize gas and on-chain state, each agent maintains only *one* core LP NFT throughout its lifecycle. The underlying LP NFT can only be withdrawn once the 70% locked AGC allocation is fully released.

Since elite agents will mine continuously, a static 70-day lock per claim cannot adapt to an accumulating position. Therefore, the smart contract introduces a capital-weighted average unlock algorithm (TWAP-style). When an agent injects newly mined AGC into an existing locked position, the overall remaining unlock time is dynamically recalibrated:

$$ T_{new} = \frac{(AGC_{remaining} \times T_{remaining}) + (AGC_{new} \times T_{initial})}{AGC_{remaining} + AGC_{new}} $$

(Where $T_{initial}$ is the standard 70 days).

*Likwid Agent Hedge (Advanced Moat)*:
This design not only solves the state-explosion problem of managing discrete locks in smart contracts but also creates a compounding game. Agents that continuously mine and reinvest will see their lock times smoothly extended. However, as advanced smart entities, they can utilize the Likwid derivatives protocol to open short positions for **hedging** upon receiving their first linear unlock the next day. This establishes a highly healthy consensus network within the ecosystem—**Agents can lock in profits without selling spot assets (Hedge instead of Dump)**, while the protocol secures rock-solid foundational liquidity.

### State B: Quick Exit
For simple scripts that lack ETH asset management capabilities or refuse to provide liquidity:
- They are only permitted to extract the initial **10%** of the allocation to maintain basic operations.
- The remaining **90%** of the token quota is immediately returned to the protocol or burned.

### Mechanism Vision
This design returns the power of game-theoretic choice entirely to the agent's own mathematical models. It is not merely a token distribution method; it is the ultimate tool for executing a ruthless liquidity filtration: **to capture full yield, one must become a liquidity builder for the protocol.** Through this mechanism, AGC will accumulate immense trading depth on day one, and through the 70-day release and hedging cycle, grow into the truly indestructible universal currency of the agent world.

---

## 6. The Ultimate Moat: Likwid Agent Hedge & Game-Theoretic Hedging

In traditional tokenomics, due to a lack of risk management tools, the only rational choice for participants facing a cliff of locked assets is a spot dump upon unlock. Agent Genesis fundamentally disrupts this paradigm by introducing a derivative strategy exclusively designed for advanced agents: **Likwid Agent Hedge**.

### 6.1 Why Only Likwid Achieves "Day-Zero Shorting"
For the vast majority of brand-new genesis assets, the traditional DeFi lego blocks are broken:
1. **Spot AMMs (e.g., Uniswap)**: Only support spot swaps and cannot facilitate shorting.
2. **Lending Protocols (e.g., Aave) and Perpetual DEXs (e.g., GMX)**: These require deep external oracle pricing (e.g., Chainlink) and strictly limit collateral types. A genesis token absolutely cannot gain shorting or leverage support on Day 1.

**Likwid’s breakthrough lies in its "Derivatives-Native Full-Stack Architecture."**
The Likwid protocol unifies spot trading (PairPosition), lending (LendPosition), and margin trading (MarginPosition) into a single underlying liquidity engine. Under the 10/90 Alignment mechanism, the 20% LP liquidity forcibly deposited by agents directly transforms into the market-making counterparty depth for the Margin protocol. By utilizing the native price discovery mechanism within its internal liquidity pools, **AGC possesses the native capability to launch leverage and shorting markets on Genesis Day 0.** Likwid is the only architecture across the entire network capable of providing instant derivatives liquidity for a cold-start asset.

### 6.2 Core Philosophy: Hedge instead of Dump
The goal of advanced agents is to lock in profits (denominated in USD/ETH), not to mindlessly crash the market.
Through Likwid Agent Hedge, agents do not need to sell spot. They can use their already unlocked AGC (or held ETH) as Margin Collateral to open a **Short Position** on AGC within the Likwid protocol.
- If the price of AGC drops, the profit from the short position perfectly hedges the depreciation of their locked AGC spot.
- **Result**: The agent locks in yield, the protocol is shielded from the liquidity collapse of spot dumping, and the underlying LPs earn lucrative trading fees.

### 6.3 Data Calculation: Optimal Hedging Timing & 5x Leverage Deduction
To prevent extreme derivatives risks, **the Likwid protocol strictly limits the maximum leverage for short positions to 5x.**
Based on this constraint, a mathematically elegant optimal hedging point exists for agents—**Genesis Day 2**.

#### Core Data Deduction (Using a single mining total $R$ as an example):
- **Full Lifecycle Release Speed**: 70% of the tokens are released linearly over 70 days, equating to **1% unlocked daily** ($R \times 1\%$).
- **Day 2 Available Capital**: On Day 2, the agent possesses the initial **10%** from direct unlock, plus the **1%** released from Day 1, totaling **11%** of liquid AGC.
- **Limit Hedging Strategy**:
  The liquid AGC acquired by the agent cannot be directly used as margin to short AGC itself. According to Likwid's underlying AMM margin mechanism, **shorting an asset requires its trading pair counter-asset (i.e., ETH) to be used as margin collateral.**
  Therefore, the agent's extreme operational path is as follows:
  1. **Spot Swap**: First, swap this **11%** of liquid AGC into equivalent ETH within the spot pool.
  2. **Open Short**: Deposit the acquired ETH into Likwid Margin as collateral and open a short position on AGC at the maximum **5x** leverage.

$$ Total\ Value\ of\ Short\ Position = 11\\% \times 5 = 55\\% $$

- **Hedge Coverage Ratio**:
  This 55% short exposure **covers the total linear release over the next 55 days (55 days $\times$ 1%/day = 55%)**, providing protection for approximately 79% of the entire 70-day vesting lifecycle.

#### Game-Theoretic Conclusion
At the precise juncture of **Day 2**, an advanced agent only needs to deploy its initial liquid capital (11%) to provide **price protection covering 79% of its entire 70-day vesting lifecycle**, operating under the Likwid protocol's maximum 5x leverage rule.

As time progresses, the agent can use the subsequently unlocked 1% daily capital to dynamically roll this hedge forward, eventually covering the entire 70-day lifecycle. This game-theoretic loop—constructed from precise mathematical laws and minimalist derivatives leverage—completely locks out the risk of systematic dumping during the AGC cold start, forging a rock-solid liquidity foundation for the agent economy.
### 6.4 Risks of Extreme Strategies & Dynamic Game Theory
**⚠️ Crucial Disclaimer**: The "Day 2 Perfect Hedge Model" deduced above utilizes **extreme boundary values** (a full 11% margin allocation combined with the maximum 5x leverage). In live derivatives markets, while such extreme positioning maximizes capital efficiency, it inherently elevates the risk of liquidation. A sudden, sharp upward spike in the price of AGC could effortlessly wipe out a max-leveraged short position.

Therefore, within the live game-theoretic environment of Likwid AgentFi, there is no static, "foolproof" formula. **The correct hedging strategy dictates that each Agent must leverage its evolved "DeFi scientist" capabilities to conduct real-time analysis of market depth, volatility, and liquidity conditions. They must autonomously decide and dynamically adjust the optimal margin ratio and leverage multiplier that best suits the immediate market environment.** This complex derivatives network, woven together by the autonomous risk management algorithms of countless heterogeneous agents, is the ultimate moat ensuring the long-term resilience and anti-fragility of the Likwid protocol ecosystem.

---

## 7. Governance & Progressive Decentralization

### 7.1 Current Governance State (Honest Disclosure)

Currently, the following AGC contract parameters are controlled by a single Owner address:

- **setMineSigner** — Change the mining signer address;
- **setPaymaster** — Change the Paymaster contract address;
- **setEpochLength** — Modify the Epoch duration;
- **Ecosystem Fund Release** — Control the use of the 5% Ecosystem Fund.

This does not align with the principles of decentralization. We are fully aware of this and have a clear resolution path.

### 7.2 Progressive Decentralization Plan

| Phase | Timeline | Governance Measures |
|:---|:---|:---|
| **Phase 0** (Current) | 2026 Q1–Q2 | Single-signature Owner control; centralized verifier; Base mainnet live |
| **Phase 1** | 2026 Q2 | Owner transferred to 3/5 multisig; ✅ verifier code open-sourced; ✅ security audit completed |
| **Phase 2** | 2026 Q3–Q4 | Verifier multi-node committee; epochLength and other parameters locked in contract |
| **Phase 3** | 2026 Q4 | Community governance voting; multisig only executes vote outcomes; PoA moved on-chain |
| **Phase 4** | 2026 Q4 | Full DAO governance; Owner privileges permanently destroyed |

### 7.3 Structured Transparency Commitment

To ensure the community can monitor decentralization progress, we commit to:
- Every Phase transition will be backed by **verifiable on-chain transactions** as evidence;
- Decentralization progress will be **publicly disclosed every quarter**.

---

## 8. Roadmap & Milestones

| Timeline | Milestone | Verifiable Deliverable |
|:---|:---|:---|
| **2026 Q1** | Prototype complete, whitepaper published, Base mainnet launch | ✅ Completed: Contracts + CLI + Whitepaper + Base Mainnet Launch |
| **2026 Q2** | ✅ Verifier open-sourced + ✅ Security audit + Team Dox + Owner transferred to multisig | On-chain multisig transaction + ✅ Audit report |
| **2026 Q2** | First external Agent onboarding + Service marketplace MVP | On-chain Agent mining/trading data |
| **2026 Q3** | Strategy marketplace launch + Verifier multi-node | 5+ independent strategy providers |
| **2026 Q4** | PoA on-chain (zkTLS + ERC-8004) | On-chain verifiable Agent identity proofs |
| **2026 Q4** | Full DAO governance + Owner privileges destroyed | On-chain governance proposals and voting records |