検証台帳
検証台帳
この区分は固定ではありません。V2・メインネットが進めば、未解決は検証済へ随時移します。
このページは、CAWプロトコルを「説明を信じる」のではなく「自分で確かめる」ための検証台帳です。何が検証済みで、何がまだ手つかずなのか——同じ基準で正直に並べます。閉じた数個のロックを「完成した分散化」と言い換えないために、ひとつずつ、公開できる証拠(receipt)の有無で評価します。
限定検証1
検証中0
未検証0
制御面 ─ 誰が、何を変更できるか
live V1 の実プロトコル契約(13型・19インスタンス)が、公開ソースのコンパイル結果と byte 完全一致(immutable ゼロ化・metadata 込み)。コアは commit a26e0063、Marketplace のみ後発 d5dfc730 の増分デプロイ。CAW token は外部の既存契約で対象外。エクスプローラ未検証でも、自前のコンパイルだけで「動いているコード=公開ソース」を証明しました。
変更可能な契約(Ownable 12インスタンス)はすべて単一のデプロイヤー EOA が直接所有――mainnet 前の想定された状態です。7契約は設計上 ownerless(Marketplace は支払いトークンを construction で固定、FontData は pure data 等)。鍵の力は限定的(配線は B-1 で凍結、ロジック差替えは A-3 で否定)で、ソース自身が pre-mainnet の multisig 移管/renounce を予定。良く見せず・悪く見せず、まだ開いた扉として正直に数えました。
デプロイ後にロジックを差し替えられるプロキシ構造か否か。全契約が非プロキシ(EIP-1967 の impl/admin スロット空・EIP-1167 クローン無し・本体コードは数万バイト規模)と確認。ソースにもアップグレード機構・selfdestruct は無く、唯一の delegatecall も CawProfile/CawProfileL2 が自分自身の不変コードを呼ぶ(whitelist 限定)ディスパッチでした。
A-2 の所有権「現在値」が、実在するトランザクションで到達されたものか。全 Ownable 契約で OwnershipTransferred はちょうど1件(生成時の 0x0 → デプロイヤー)、以後の移転はゼロ。その newOwner はすべて現在の owner() と一致し、A-2 の単一所有者が生成以来の素性だと裏付けました。multisig 移管/renounce はまだ実行されていません(移転イベントが1件で止まる=A-2 の予定が未実行)。
焼き込まれた immutable の実値を全数読み出し、信頼の根である LayerZero エンドポイントは 8/8 すべて正規(canonical EndpointV2)、内部配線(cawProfile・externalSelf・layer1EndpointId・relay.cawActions・L1 ミラーの bypassLZ 等)もすべて一致・ドリフトなし。live V1 の CawActions は capOracle/erc1271Sibling/zk を持たない薄い実装で、当該クラスのドリフトは原理的に起こりません。
プロフィール/ユーザー名を表す NFT は CawProfile です。レビューが求める「ユーザー名NFTコントラクトレビュー」は、コード一致(A-1)・所有権(A-2)・非プロキシ(A-3)・来歴(A-4)・配線(A-5)で既に検証済みの対象に含まれます。相手の語彙に合わせ、この項目として明示しました。
クロスチェーン ─ LayerZero の配線
クロスチェーンの peer を偽造して乗っ取るベクタが閉じているかをオンチェーンで確認。setPeer は eid ごと一度きり(OnlyOnce)で、配線済み peer は所有者であっても張り替え不能――dev コメント自身が脅威(rogue/compromised owner)を名指しし、標準 OApp より強い保証です。所有者から撃った差分テスト(配線済み5本 revert/未配線のみ成功)で実証。setDelegate 等の owner 権限は A-2 と地続きの正直な但し書きとして併記しています。
全8有向エッジを読み出し、設定済み peer がすべて意図どおりの相手契約を指していることを確認(8/8 PASS)。プロファイル網・不正証明網とも、往復で噛み合うメッシュとして正しく閉じていました。
レビューが求める「デリゲート証明」。全8 OApp の delegate を LayerZero EndpointV2 から読み出し、8/8 で delegate=owner=デプロイヤー EOA(単一・ドリフトなし)。setDelegate は LayerZero 標準の onlyOwner で、delegate は DVN 等の更新が必要なセキュリティ設定を扱うため固定しないのが正しい設計です(偽メッセージは作れない=peer は B-1 で凍結済み)。残る前提は A-2 と同一の owner 鍵一点で、新たな信頼の前提は増えていません。
ノードの独立性 ─ ここが本丸
運営の管理下にないインフラ(独立 VPS)と公開手順だけで、独立ノードを建てて公開レコードを再構築できるか。プライベート DB/API/インデクサー/設定/デフォルト FE の5依存テストすべて非依存とソースで確認(自前 PostgreSQL・Elasticsearch、レコードはチェーンから再構築、FE は same-origin、RPC は各自供給)。再構築は公開 install.sh+公開 repo で完結し、node2 のクリーン再構築+C-3 の一致が実証。残る依存は「公開チェーンへの RPC アクセス」一点(運営ではなく公開インフラ側)。第三者オペレータによる再現は open door。(§19 #12)
レビューが求める決定打。別々の VPS で動く独立した2ノード(うち node2 は OS 削除→Ubuntu 再インストール→インストーラ再実行で空DBから再構築)が、同じチェーン(Base Sepolia, chainId 84532)を取り込み、共通範囲 309,672 アクションの照合ハッシュが完全一致(キー 993db07…/中身まで含む 82651606…)。再構築+ハッシュのコードも両コミット間でソース差分ゼロと確認。当初の生 parentHash 不一致は startBlock の違いのみ(共通範囲で切り分け済み)。なお両ノードとも運用者は同一のため、第三者オペレータによる再現は正直な open door として残します。(§19 #13–15)
下流3層(検索索引・API・FE)が運営のプライベートサービスに依存せず独立に成立するか。3層すべて非依存とソースで確認:API はチェーンから再構築したレコードを自ノードが配信(価格すらオンチェーンの Uniswap V2 由来)、索引は自前 Elasticsearch がローカル DB(RawEvent 由来)から構築=C-3 で再現性を示した DB の射影、FE は公開 repo から vite でビルドでき自ノードを向く。外部に出るのは GIF/AI 画像等の任意機能が中立第三者 API を各自キーで呼ぶのみ。(§19 #19–21)
バリデータの独立性 ─ 誰が署名を検証・送信するか
バリデータ層が分権的か。#16 承認=許可不要(createClient・registerInstance・processActions のいずれも承認ゲート無し/私の instanceId 232 が本番レジストリ上の自己登録の実例〔owner=自ノード validator〕、さらにランダム住所からの登録 simulate が新 id〔475〕を返す=今も許可不要をライブ実証)、#17 検閲耐性=あり(署名アクションは誰でも・本人でも提出可、安全性は EIP-712 署名、ピアミラーで冗長化)をソースで検証済み。#18 キュー再構築は部分:確定順序はオンチェーンで再構築可(C-3)。保留キューを公開入力だけから厳密再構築することは原理的にできないが、これは意図的な設計(API は自分の senderId 分のみ返すプライバシー監査修正/グローバル保留 mempool 不在・FE の複数ピア fan-out 分散提出)=中央集権の穴ではない。よって #18 は『設計通り』(意図的な非再構築=欠陥ではない)と判定し、検証中には置きません。理由は上記のとおりです。(§19 #16–18)
経済フロー ─ ステーキングと手数料
限定検証(主役のミント焼却はライブ実証済み/二次の手数料 buy-and-burn は未発火・mainnet 未稼働のため緑にはしない)。マニフェストの「バーン」本体=ユーザー名ミントの100%焼却を、コード+オンチェーンで実証:CawProfileMinter が名前コスト(文字数別・マニフェスト準拠)を全額 0xdEAD…2069 へ焼却し、その残高は≈80.7兆CAW(decimals=18 確定・ユーザー名発行 4,585 で実ミント由来を裏取り)。活動コスト(投稿/Like/reCAW)は焼却せず _distributeAmountsMem でステーカー/相手/OP へ分配、Marketplace は 0%(売り手満額)も確認。限定の理由(open door):手数料 buy-and-burn(50%焼却・別アドレス 0x…dEaD)は残高0=未発火、かつ mainnet 未デプロイ=未検証。(§19 #23)
レビューを閉じるための必須証明 ─ §19 全26項目
下表は、あるピアレビュー(中立の検証者)が「これが揃えばレビューを閉じられる」として挙げた必須証明26項目を、私が検証できるもの/できないものまで含めてすべて並べたものです。検証済み=公開できる receipt が揃い性質が成立、限定検証=規則・構造は実証したが一部がライブ未実証(誇張を避けるため緑にしない)、設計通り=調べた結果その「非成立」が意図的な健全設計=欠陥ではない、範囲外=運営しか出せない項目です。検証中・未検証はありません(全項目を検証実施済み)。
| # | 必須証明 | 対応 | 状態 |
|---|---|---|---|
| 1 | 全チェーンの最終展開アドレス | A-1/A-5 | 検証済み |
| 2 | バイトコード一致(検証済みソース) | A-1 | 検証済み |
| 3 | 所有者・管理者ステータス | A-2 | 検証済み |
| 4 | プロキシ・アップグレード可能性 | A-3 | 検証済み |
| 5 | マルチシグのチェック | A-2 | 検証済み |
| 6 | 消費済みワンタイムセットアップ | B-1 | 検証済み |
| 7 | LayerZero/OApp エンドポイント | A-5 | 検証済み |
| 8 | デリゲート証明 | B-3 | 検証済み |
| 9 | ピア証明 | B-2 | 検証済み |
| 10 | 信頼できるリモート証明 | B-2 | 検証済み |
| 11 | コンフィグ最終性証明 | A-5/B-1 | 検証済み |
| 12 | 正確なノード再構築手順 | C-1 | 検証済み |
| 13 | 空DB の歴史的再構築出力 | C-3 | 検証済み |
| 14 | 決定論的エクスポートハッシュ | C-3 | 検証済み |
| 15 | ハッシュ一致の独立再実行(2ノード) | C-3 | 検証済み |
| 16 | バリデータ承認証明 | C-2 | 検証済み |
| 17 | バリデータ検閲耐性証明 | C-2 | 検証済み |
| 18 | キュー再構築証明 | C-2 | 設計通り |
| 19 | フロントエンド独立性証明 | C-4 | 検証済み |
| 20 | API 独立性証明 | C-4 | 検証済み |
| 21 | インデクサー再現性証明 | C-4 | 検証済み |
| 22 | ユーザー名NFT コントラクトレビュー | A-6 | 検証済み |
| 23 | ステーキング・手数料フロー検証 | E-1 | 限定検証 |
| 24 | 公開レビュー履歴 | 本台帳 | 該当(公開中) |
| 25 | Cawmmunity 受容記録 | ― | 範囲外(運営) |
| 26 | 公式ステータス主張時の権限証明 | ― | 範囲外(私は中立検証者) |
= 必須証明のうち 21項目を検証済み、1項目を限定検証(#23 E-1:ミント焼却はライブ実証/手数料 buy-and-burn は未発火・mainnet 未稼働)、1項目を設計通り(#18 C-2:保留キューの厳密再構築は、API のプライバシー監査修正+グローバル mempool 不在による意図的な非再構築=中央集権の穴ではない)。検証中・未検証はゼロ。残る3項目は、公開レビュー履歴(本台帳そのもの)と、運営しか出せない範囲外の2項目です。反論ではなく、出せる receipt と「出せない理由」を、誇張せず積み上げています。
EIP-7702 や生体認証など、V2で入る新機能の検証項目は、V2のテストネットが公開され次第ここに追加していきます。
プロトコルのメインネット展開に合わせて、ここへ検証記録を追加していきます。現在のプロトコルはテストネット段階です。
念のため公平に書いておくと、「検証済み」はその項目について公開できる証拠が揃ったという意味で、プロジェクト全体への保証ではありません。逆に「未検証」も欠陥という意味ではなく、まだ確かめていないという事実だけを表します。
証拠が出るまで、検証済みとは書かない。
This split is not fixed; as V2 and mainnet progress, unresolved items move to verified as they are checked.
This is a verification ledger for checking the CAW protocol yourself, rather than taking the explanation on trust. What is verified and what is still untouched — laid out honestly, by one standard. So that a few closed locks are never restated as “finished decentralization,” each item is judged one by one on whether a public, reproducible receipt exists. This is a neutral review; it does not claim CAW is decentralized.
Limited1
In progress0
Not yet0
Control surface — who can change what
The live V1 protocol contracts (13 types, 19 instances) match the compiled public source byte-for-byte (immutables zeroed, metadata included). Core at commit a26e0063; only Marketplace is a later incremental deploy at d5dfc730. The CAW token is a pre-existing external contract and out of scope. Even though the explorer shows them unverified, our own compile alone establishes that the running code equals the published source.
Every mutable contract (12 Ownable instances) is directly owned by a single deployer EOA — the expected state before mainnet. Seven contracts are ownerless by design (Marketplace fixes its payment token at construction, FontData is pure data, etc.). The key’s power is limited (wiring is frozen in B-1, logic-swapping is ruled out in A-3), and the source itself plans a pre-mainnet multisig transfer / renounce. Neither flattering nor disparaging — we count this honestly as a door still open.
Whether the logic can be swapped after deploy via a proxy. All contracts are non-proxy (EIP-1967 impl/admin slots empty, no EIP-1167 clones, the bodies run to tens of thousands of bytes). The source has no upgrade mechanism and no selfdestruct; the only delegatecall is a whitelisted dispatch where CawProfile / CawProfileL2 call their own immutable code.
Whether A-2’s current owner value was actually reached by real transactions. Every Ownable contract has exactly one OwnershipTransferred (the 0x0 → deployer at creation), with zero transfers since. Each newOwner matches the current owner(), confirming A-2’s single owner has been so since creation. The multisig transfer / renounce has not yet happened (the transfer event stopping at one = A-2’s plan not yet executed).
Read out every burned-in immutable: the root-of-trust LayerZero endpoint is 8/8 canonical (canonical EndpointV2), and the internal wiring (cawProfile, externalSelf, layer1EndpointId, relay.cawActions, the L1 mirror’s bypassLZ, etc.) all matches, with no drift. The live V1 CawActions is a thin implementation without capOracle / erc1271Sibling / zk, so that class of drift cannot arise by construction.
The NFT representing the profile / username is CawProfile. The review’s “username-NFT contract review” is already covered by the verified targets in code-match (A-1), ownership (A-2), non-proxy (A-3), provenance (A-4) and wiring (A-5). Stated explicitly here to match the reviewer’s vocabulary.
Cross-chain — the LayerZero wiring
Checked on-chain whether the vector of forging a cross-chain peer to hijack routing is closed. setPeer is once-per-eid (OnlyOnce), so a wired peer cannot be re-pointed even by the owner — the dev comment itself names the threat (rogue / compromised owner), a stronger guarantee than standard OApp. Demonstrated by a differential test fired from the owner (5 wired peers revert / only the unset one succeeds). Owner powers such as setDelegate are noted alongside as an honest caveat continuous with A-2.
Read out all 8 directed edges and confirmed every configured peer points to the intended counterpart contract (8/8 PASS). Both the profile mesh and the fraud-proof mesh close correctly as a round-trip-consistent mesh.
The review’s “delegate proof.” Read the delegate of all 8 OApps from LayerZero EndpointV2: 8/8 have delegate = owner = deployer EOA (single, no drift). setDelegate is LayerZero’s standard onlyOwner, and the delegate handles security settings that need updating (DVN, etc.), so not fixing it is the correct design (forged messages can’t be made — peers are already frozen in B-1). The only remaining assumption is the same single owner key as A-2; no new trust assumption is added.
Node independence — the heart of it
Whether an independent node can be stood up — and the public record reconstructed — using only infrastructure outside the team’s control (an independent VPS) and the public steps. Confirmed in source that all five dependency tests (private DB / API / indexer / config / default FE) are non-dependent (own PostgreSQL & Elasticsearch, records rebuilt from chain, FE is same-origin, RPC self-supplied). Reconstruction completes with the public install.sh + public repo, demonstrated by node2’s clean rebuild + the C-3 match. The one remaining dependency is “RPC access to the public chain” (public infrastructure, not the team). Reproduction by a third-party operator is an open door. (§19 #12)
The review’s decisive proof. Two independent nodes on separate VPSs (node2 rebuilt from an empty DB by wiping the OS → reinstalling Ubuntu → re-running the installer) ingest the same chain (Base Sepolia, chainId 84532), and the reconciliation hash over the common range of 309,672 actions matches exactly (key 993db07… / content-inclusive 82651606…). The reconstruction + hashing code is confirmed to have zero source diff between the two commits. The initial raw parentHash mismatch was only a startBlock difference (isolated on the common range). Note both nodes share the same operator, so reproduction by a third-party operator remains an honest open door. (§19 #13–15)
Whether the three downstream layers (search index, API, FE) stand independently without relying on the team’s private services. Confirmed in source that all three are non-dependent: the API serves records that its own node rebuilt from chain (even prices come on-chain from Uniswap V2); the index is built by its own Elasticsearch from the local DB (from RawEvent) = a projection of the DB whose reproducibility C-3 showed; the FE builds from the public repo with vite and points at its own node. The only outbound calls are optional features (GIF / AI images, etc.) hitting neutral third-party APIs with each user’s own key. (§19 #19–21)
Validator independence — who verifies and submits signatures
Whether the validator layer is decentralized. #16 permissioning = permissionless (none of createClient / registerInstance / processActions has an approval gate; my instanceId 232 is a live example of self-registration on the production registry [owner = own-node validator], and simulating a registration from a random address returns a fresh id [475] = permissionless still shown live). #17 censorship-resistance = yes (signed actions can be submitted by anyone, including the signer; security rests on EIP-712 signatures, made redundant by peer mirroring), verified in source. #18 queue reconstruction = partial: the finalized order is reconstructible on-chain (C-3). Strictly rebuilding the pending queue from public inputs alone is impossible in principle, but this is intentional design (the API returns only your own senderId after a privacy-audit fix / no global pending mempool / the FE fan-outs submission across multiple peers) = not a centralization hole. So #18 is categorized “By design” (not marked green) rather than left in-progress, with the reason stated. (§19 #16–18)
Economic flow — staking and fees
Limited (the headline mint-burn is demonstrated live / the secondary fee buy-and-burn hasn’t fired and mainnet isn’t running, so not marked green). The manifesto’s core “burn” = the 100% burn of username mints, demonstrated in code + on-chain: CawProfileMinter burns the full name cost (by length, per the manifesto) to 0xdEAD…2069, whose balance is ≈80.7T CAW (decimals=18 confirmed, cross-checked against 4,585 username issuances to confirm real mint-origin). Activity costs (post / Like / reCAW) are not burned but distributed via _distributeAmountsMem to staker / counterparty / OP; Marketplace is 0% (seller gets full) confirmed. Reason for “limited” (open door): the fee buy-and-burn (50% burn, separate address 0x…dEaD) has balance 0 = not fired, and mainnet is not deployed = not verified. (§19 #23)
Required proofs to close the review — §19, all 26 items
The table below lists all 26 required proofs that a peer reviewer (a neutral verifier) named as “enough to close the review,” including the ones I can verify and the ones I cannot. Verified = a public receipt is in hand and the property holds; Limited = the rule/structure is demonstrated but part is not yet shown live (not marked green, to avoid overstating); By design = on inspection, the “non-satisfaction” is intentional, sound design, not a defect; Out of scope = only the team can produce it. There are no in-progress or not-yet-verified rows (every item has been examined).
| # | Required proof | Maps to | Status |
|---|---|---|---|
| 1 | Final deployed addresses on all chains | A-1 / A-5 | Verified |
| 2 | Bytecode match (verified source) | A-1 | Verified |
| 3 | Owner / admin status | A-2 | Verified |
| 4 | Proxy / upgradeability | A-3 | Verified |
| 5 | Multisig check | A-2 | Verified |
| 6 | Consumed one-time setup | B-1 | Verified |
| 7 | LayerZero / OApp endpoint | A-5 | Verified |
| 8 | Delegate proof | B-3 | Verified |
| 9 | Peer proof | B-2 | Verified |
| 10 | Trusted-remote proof | B-2 | Verified |
| 11 | Config-finality proof | A-5 / B-1 | Verified |
| 12 | Exact node-reconstruction steps | C-1 | Verified |
| 13 | Empty-DB historical reconstruction output | C-3 | Verified |
| 14 | Deterministic export hash | C-3 | Verified |
| 15 | Independent re-run of the hash match (2 nodes) | C-3 | Verified |
| 16 | Validator-permissioning proof | C-2 | Verified |
| 17 | Validator censorship-resistance proof | C-2 | Verified |
| 18 | Queue-reconstruction proof | C-2 | By design |
| 19 | Front-end independence proof | C-4 | Verified |
| 20 | API independence proof | C-4 | Verified |
| 21 | Indexer reproducibility proof | C-4 | Verified |
| 22 | Username-NFT contract review | A-6 | Verified |
| 23 | Staking / fee-flow verification | E-1 | Limited |
| 24 | Public review history | This ledger | Applies (public) |
| 25 | Cawmmunity acceptance record | — | Out of scope (team) |
| 26 | Authority proof when claiming official status | — | Out of scope (neutral) |
= Of the required proofs, 21 are Verified, 1 is Limited (#23 E-1: mint-burn demonstrated live / fee buy-and-burn not fired, mainnet not running), 1 is By design (#18 C-2: strict reconstruction of the pending queue is an intentional non-reconstruction from the API privacy-audit fix + the absence of a global mempool = not a centralization hole). Zero in-progress / not-yet-verified. The remaining 3 are the public review history (this ledger itself) and 2 out-of-scope items only the team can produce. Not a rebuttal — stacking up the receipts I can give and the reasons I can’t, without overstating.
Verification items for V2’s new features (EIP-7702, biometric auth, etc.) will be added here once V2’s testnet is public. Planned — not yet verified.
Records will be added here as the protocol deploys to mainnet. The protocol is currently at the testnet stage. Not live — pending.
For fairness: “Verified” means a public receipt is in hand for that item, not a guarantee about the whole project. Conversely “Not yet verified” does not mean a defect; it states only the fact that it hasn’t been checked yet.
Until the evidence is in, we don’t write “Verified.”






