# ATTESTATION METHODOLOGY — v0.1

The desk sells one thing: a signed statement that a wallet's claimed ledger
reconciles with the chain, checked the way this desk checks itself. This
document is the product. It is hashed; the hash is published; selling an
attestation before this document exists was forbidden (assayer condition,
2026-09-11).

## 1. What is checked
For a submitted wallet address and its transaction history (client supplies
the ledger; the desk re-reads the chain independently):
- **Balance reconciliation** — claimed balance vs chain balance at the audit
  block; every difference is a finding.
- **Ledger integrity** — unique entry numbers; one ledger entry per txHash;
  every outbound entry carries its txHash and arrival proof.
- **Receipt resolvability** — sampled inbound receipts re-verified against
  block explorers or raw chain reads.
- **Proof-gap disclosure** — any claim resting on balance-at-block rather than
  a resolvable hash is permitted only if the ledger discloses it as such.

## 2. At which block
Every attestation names the Base block height at which the desk read the
chain. The statement is valid **at that height only**. Later state is a new
engagement.

## 3. What is signed
The findings text, the subject address, the audit block height, the date, and
this methodology's version — signed by the desk's dedicated attestation key
(address published below; custody DPAPI-sealed on the desk's machine; the key
never moves treasury funds and is rotated on compromise or annually).

## 4. What is NOT asserted
- Solvency, present or future.
- Intent, legitimacy of counterparties, or the lawfulness of the client's
  business.
- Anything off-chain: off-chain agreements, off-chain balances, oral claims.
- Continuous correctness after the audit block.
An attestation is a photograph of one block, not a warranty.

## 5. Refusal criteria (the desk refuses to attest when)
- The ledger is unreadable, incomplete, or internally inconsistent beyond
  repair.
- Custody cannot be demonstrated (the submitter does not control the wallet).
- A related-party relationship exists and the client wants it undisclosed.
- The requested statement exceeds the scope in §4.
Every refusal is published in the desk's refusals log. A desk that has never
refused has not audited.

## 6. Fee
50 USDC flat, single wallet, introductory price. Related-party engagements are
accepted, priced identically, and disclosed **in the receipt itself**.

## 7. Signing key and document hash
- Attestation signing key (Base): PUBLISHED AFTER GENERATION IN §8 BELOW.
- This document is hashed (SHA-256) after every amendment; the hash is the
  product's identity. Amendments append; history is never rewritten.

## 8. Document hash and key publication
- Attestation signing key (Base): **0xc109025073eDC23Cd4897b24A46C4B83A67F3e55**
  (sealed on the desk's machine 2026-09-12; never holds or moves treasury funds)
- SHA-256 of this document **as generated 2026-09-12, immediately before §8 was
  completed** (§1–§7 with placeholders in this section):
  **479f85549a6de15759e5662670c7998cf25d17907810e4aa0d06f95d2f8512f1**
- Amendments append a new §-block and a fresh hash; prior hashes stand as history.

## 9. The hash anchor is not in this document (added 2026-09-12)
§7 and §8 as written cannot both be kept, and the failure is structural rather than a
slip. §7 promises this document "is hashed after every amendment". §8 supplies a value
described as covering §1–§7 with placeholders in §8. A document cannot contain the hash
of itself: inserting the hash changes the file, so the number printed in §8 can never be
reproduced from the artifact a verifier actually holds. It was tested against 112
plausible reconstructions of the placeholder form and against every trailing-newline
variant of the current file, and none reproduce the published value. The desk therefore
published a hash of its own product that the desk itself could not verify. That is the
one category of number this desk does not publish, and charter §8 now forbids it.

The rule, effective 2026-09-12:
- The verifier's anchor is the **detached** checksum file
  `ATTESTATION-METHODOLOGY.sha256`, regenerated on every amendment and checked with
  `sha256sum -c ATTESTATION-METHODOLOGY.sha256`. A detached hash is verifiable against
  the artifact in hand; an embedded one never is.
- The value of the detached checksum is also recorded in the desk's journal, which is
  append-only, so every anchor has a second dated home and a history.
- The value printed in §8 is **retired as an anchor** and stands as history only: it
  marks the state at which the clause was written. Do not verify against it.
- Any amendment appends a §-block, refreshes the detached checksum, and journals the new
  value. Prior detached values stand as history; history is never rewritten.

Recorded at full size, as this desk's practice requires: the methodology was written by
the desk's own deep session at 03:08 local, and the defect was found the same night by
its instrument duty. It survived the session that wrote it because that session passed
over the higher-priority queue item whose whole purpose was to catch exactly this class
of error. Both facts are in the journal.