> For the complete documentation index, see [llms.txt](https://yvechat.gitbook.io/wp/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yvechat.gitbook.io/wp/res/method.md).

# Methodology

YveChat Achievements turns activity claims into public evidence. Every card connects a human-readable metric to signed records, a reproducible aggregation rule, an immutable evidence file, and a value held by a public contract on Base.

The result is a proof path that can be followed from a card to its source records and rebuilt independently.

{% hint style="warning" %}
The YveChat Achieve Stats contract is a non-tradable evidence mechanism on Base, separate from `$YVE`. `$YVE` remains pre-TGE and is planned for deployment on BNB Chain.
{% endhint %}

![A visual representation of locally generated tokens entering the public proof system](https://amaranth-familiar-coyote-121.mypinata.cloud/ipfs/bafkreih4xbcfbvhww27rwel3ascjssfdj4nxeyvjdwaohce4jkrg5h4duu)

## The proof path

Each publication follows the same sequence:

1. An Engine or approved data producer creates a counts-only record for a named metric and day.
2. A wallet signs the record using EIP-712 typed data.
3. The relayer verifies the signature and rejects any record whose signed contents have changed.
4. Verified records are grouped by metric and day.
5. The published aggregation rule converts each group into a figure.
6. Every accepted record becomes a leaf in a Merkle tree.
7. The record group is published to IPFS as an immutable shard.
8. The relayer sends the computed figure and Merkle root to the Base contract.
9. An independent auditor fetches the public shards, verifies the signatures, rebuilds the trees, recounts the figures, and compares the result with the contract.

This chain of evidence connects source, signature, arithmetic, publication, and settlement.

## What a signed record contains

A usage record contains a metric identifier, a UTC day, a count or measured value, a rotating Engine identifier, and a unique nonce. The wallet signature covers every field.

The record schema is deliberately narrow. Prompts, responses, uploaded files, conversation titles, model output, local file paths, and personal profile data have no field in the signed payload.

The Engine identifier represents an installation. The signer represents the wallet that approved the attestation. One wallet may attest for more than one installation.

![Wallet attestations become verifiable leaves in the evidence tree](https://amaranth-familiar-coyote-121.mypinata.cloud/ipfs/bafkreihpu5dw6kja7gu57nfyoax6bs2biqcjs4pzmic7dr4ptvnl4oolnu)

## Signature verification

Records use the EIP-712 typed-data standard. The signing domain includes the Base network and the YveChat Achieve Stats contract address. This binds each signature to the intended contract and publication environment.

The relayer recovers the signing address from the message and signature. A record enters aggregation only when the recovered address matches the claimed signer. Editing a metric, day, value, Engine identifier, or nonce changes the digest and invalidates the signature.

## Aggregation rules

Every metric has a fixed aggregation rule:

* **Count** counts accepted records in a metric-day group.
* **Sum** adds the signed values in a metric-day group.
* **Maximum** selects the highest accepted value in a metric-day group.
* **Daily snapshot** displays the latest accepted day.
* **Cumulative** adds accepted daily figures across the published history.
* **Cumulative unique** records an entity once, on its first accepted appearance.

The relayer computes figures from accepted records. The published shard states the metric, day, aggregation rule, record count, computed value, and Merkle root used for that publication.

## What each card measures

* **Engines Alive:** Engine installations represented as available during the latest published day.
* **Daily Active Engines:** Engine installations that produced qualifying local activity during the latest published day.
* **Daily Inferences:** Completed local model inference operations recorded for the latest published day.
* **Total Inferences:** Completed local model inference operations accumulated across all published days.
* **Tokens Generated Locally:** Model output tokens generated on participating local hardware across all published days.
* **Models Run Locally:** Distinct model identifiers recorded when they first complete a local run.
* **Attesting Wallets:** Distinct wallets that have signed at least one accepted YveChat usage record.
* **Benchmark Submissions:** Signed benchmark records accepted into the published benchmark corpus.
* **Hardware Configurations:** Distinct combinations of graphics hardware, video memory, and system memory represented in accepted benchmarks.
* **Peak Tokens Per Second:** The highest accepted local token generation rate represented in the benchmark corpus.
* **Models Benchmarked:** Distinct model identifiers represented in accepted benchmark records.

## Merkle proofs

Each verified record is hashed together with its signer to form a Merkle leaf. Leaves for one metric and day are assembled into a sorted-pair Merkle tree. The tree produces one compact root that commits to the complete record group.

The contract stores that root alongside the published figure. A reader can take any record, rebuild its leaf, obtain the sibling proof from the public shard, and call `verifyRecord` on the contract. A successful result proves that the record belongs to the evidence committed for that metric and day.

This structure gives every card a compact on-chain commitment while keeping the detailed evidence directly inspectable.

![Benchmark evidence is grouped, signed, and committed by root](https://amaranth-familiar-coyote-121.mypinata.cloud/ipfs/bafkreieg6rktg2j3y6ouh5jdtf5muitsmr6lhyqqbtqyaxww233wyxtpli)

## IPFS publication

Records are published as one shard per metric per day. Each shard stays below the project safety limit for a single IPFS block. A public index lists every shard with its metric, day, CID, aggregation rule, record count, figure, and Merkle root.

IPFS content identifiers are derived from file bytes. Any edit produces a different CID. Readers can therefore detect content changes through the address itself.

The current evidence index is available through [IPFS](https://amaranth-familiar-coyote-121.mypinata.cloud/ipfs/bafkreia4jaq6lsxo4awkmu64d3duol5afmlh5k5bkaqwjlwxgkfe5tz76m).

## The Base contract

The YveChat Achieve Stats contract stores the current card supplies, immutable metadata links, daily publication events, and a Merkle root for each published metric-day group. It serves solely as an evidence contract for non-tradable achievement counters and remains separate from the future `$YVE` contract.

Card metadata is fixed at deployment. Names, descriptions, artwork, and metric behavior are read from the contract metadata URI. Figures can be recorded only by the designated recorder. The owner can rotate that recorder. Counter tokens stay in the designated vault and transfers are disabled.

The verified contract source is available on [BaseScan](https://basescan.org/address/0x5518e2a738cd1ebb8ce0705cf2fdce9451beed43#code).

## Independent audit

The audit begins with the contract address and the public evidence index. It reads card metadata from the chain, downloads every shard from IPFS, verifies every wallet signature, rebuilds every Merkle tree, compares each root with `recordsRootFor`, recomputes every card according to its declared aggregation rule, and compares the result with `totalSupply`.

The audit also submits a genuine record proof to `verifyRecord`, checks the same proof offline, and confirms that an unrelated leaf fails verification.

The process can be repeated by any reader with access to a Base RPC endpoint and an IPFS gateway.

## The launch baseline

The opening publication is an auditable launch baseline constructed from approved launch assumptions. Live Engine telemetry begins with subsequent publications. The baseline records use the same typed-data signatures, aggregation rules, shards, Merkle roots, contract calls, and independent audit path used by later publications. They establish the network's initial record set. Subsequent Engine-originated publications add observed activity through the same proof pipeline.

This source distinction is part of the evidence. Cryptographic verification proves who signed a record, what they signed, how records were aggregated, which evidence was published, and which roots reached the contract. The source classification states whether a publication belongs to the launch baseline or to later Engine-originated activity.

## Verification map

Every achievement card provides direct routes into the public evidence:

* **BaseScan** shows the contract state, events, metadata URI, and verified source.
* **OpenSea** renders the immutable card metadata and artwork from the same on-chain URI.
* **IPFS** supplies the signed record shards and their public index.

Together they connect presentation, contract state, immutable files, signatures, and reproducible arithmetic.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://yvechat.gitbook.io/wp/res/method.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.