reader

nablaz-sdk

エージェントの支払い権限を読み取るオープンソースのリーダーです。公開チェーンデータから、あるアドレスに許可されていた支出、実際の支出、その条件を再構築し、それぞれの事実に、それを再現するコマンドを添えて保持します。NablaZ のレコードと受取人のボールト、Coinbase の支払い権限、MetaMask の委任、Agent Credit Lines を読み取ります。

キーを保持せず、アカウントも API キーも不要で、RPC エンドポイントがあればどこでも実行できます。

読み取るデータ

Arbitrum One と Base の両方が有効になっています。NablaZ のコントラクトは Arbitrum One でのみ稼働しているため、Base ではサードパーティーのソースのみをインデックス化します。

両方のチェーンで利用できるサードパーティーのソース：

• Coinbase SpendPermissionManager：SpendPermissionApproved、SpendPermissionUsed、SpendPermissionRevoked。
• MetaMask DelegationManager（delegation framework v1.3.0）：すべての caveat をデコードした RedeemedDelegation。各償還について、リーダーはトランザクションレシートを読み込み、委任者が送信した ERC-20 Transfer を保持します。償還だけでは支払いとはみなされず、そのような Transfer のみが支払いとなります。
• Agent Credit Lines（Borrowed、Repaid、Defaulted）：設定された貸し手のものです。現在、どちらのチェーンにも貸し手は確認されていないため、登録された貸し手はいません。デコーダーにはテストが用意されており、何もインデックス化されていない状態で読み取ると、ブロック範囲とともに「何もインデックス化されていません」と表示されます。
• ERC-8004：「Reputation Registry」の NewFeedback（どの agentId が誰から評価されたか、およびその場所。フィードバックの値、小数点以下の桁数、タグ、エンドポイント、URI は対象外）、ならびに Identity Registry の MetadataSet と ERC-721 Transfer による agentWallet と所有者の履歴。アドレスは src/generated/erc8004.json に記載されています（ベンダーのコミットは同ファイル内に固定されています）。

デプロイされている場所での NablaZ のソース：

• NablaRecord の RecordEntry（すべてのフィールド）。
• アカウントを検出するための NablaAccountFactoryPermanent と AccountRegistryV6 の AccountCreated。
• 検出されたすべてのアカウントプロキシの ERC-1967 Upgraded。
• 承認者または送信者が受取人のボールトである場合の USDC AuthorizationUsed と Transfer。ボールトはログのみから検出されます。PAY_AUTHORIZED エントリーにボールトが記載され、同じトランザクション内の資金供給を示す Transfer によって確認されます。

出力する内容

テーブル	1 行あたり
record_entries	RecordEntry、生データ
obligation_pairs	OBLIGATION_OPENED／REPAY／OBLIGATION_CLOSED エントリー。obligationRef ごとにグループ化
vault_payments	決済：Vault の AuthorizationUsed とその Transfer のペア、およびそれが使用した grant と envelope
implementation_history	アカウントごとの Upgraded ログまたは IMPLEMENTATION_CHANGED エントリー
counterparties	重複のない（subject、counterparty）のペア。最初の証拠と件数を含む
accounts、grants、vaults、vault_fundings	上記のテーブルの構築に使用する検出およびペアリングの状態
factory_accounts	永続的な factory 上で作成されたアカウント。factory 自身のイベントから取得した owner を含む
external_permissions	spend permission または引き換えられた delegation。その形式、ラベル、デコードされた条件を含む
external_payments	SpendPermissionUsed、または redemption のトランザクションにおける delegator からの ERC-20 Transfer
external_redemptions	RedeemedDelegation。値が移動したかどうかは問いません
credit_line_events	設定済みの貸し手における Borrowed／Repaid／Defaulted
feedbacks	ERC-8004 NewFeedback：agentId、rater、feedback index。値、タグ、URI は含みません
agent_wallets	agentWallet キーに対する ERC-8004 MetadataSet：agentId と wallet（クリア時は null）
agent_owners	ERC-8004 identity の Transfer（ERC-721）：agentId と新しい owner

行には事実と件数が記録されます。リーダーは事実を述べ、いかなる対象についても評価を下しません。

vault_payments では、決済トランザクションを送信した当事者（tx.from）を submitter として記録します。counterparty として扱われることはありません。counterparty は Transfer の受取人です。

決済では NablaRecord エントリーは書き込まれません。支払いの記録は 2 つの部分からなり、リーダーがペアにします。アカウントが資金を grantee vault に予約した際に書き込んだ PAY_AUTHORIZED エントリー（予約。record_entries 内）と、USDC 自体の AuthorizationUsed および Transfer イベント（決済。vault_payments の 1 行）です。支払いを引用する場合は、両方を引用します。PAY_AUTHORIZED ログ（block、transaction hash、log index）と、USDC の決済トランザクションおよびその block です。

引用ルール

ログが真実の情報源であり、このリーダーはログを便利に参照するためのものです。各行には、証拠となる chain id、block number、transaction hash、log index に加えて、任意の RPC からそのログを取得する cast logs コマンドと同等の raw eth_getLogs リクエストが含まれます。コマンドで再現できない行があれば、それはバグです。

ログからの読み取りではないフィールドが 1 つあります。vault_payments の envelope の有効期限です。このフィールドには「state read — needs archive RPC」とラベル付けされています。リーダーは、アカウントの mandate に対して block N−1 と決済 block N の時点で envelopeOf(account, granteeKey, token) を呼び出し、両方の呼び出しを cast call --block コマンドとして保存します。2 つの読み取り結果が一致すれば、その値が保存されます。異なる場合、envelope は block N 内に変更されており、両方の読み取り結果を引用して、フィールドには「not determinable」と保存されます。2026-10-23 には、head より 50,000 blocks 前の同一の履歴 eth_call に対し、https://arb1.arbitrum.io/rpc では 10 回中 6 回応答があり、残りの 4 回は「historical state … is not available」を返しました。そのため、このフィールドについては公開エンドポイントを頼りにできません。それ以外のすべては、任意の RPC 上でログから再構築できます。

読み取り

GET /read/:chainId/:address は、アドレスに関するインデックス済みのすべての事実を返します。公開ログの読み取りを行うエンドポイントなので、キーは不要です。

{ "subject": "0x…", "chainId": 8453, "asOfBlock": "53160200",
  "facts": [ { "source": "metamask:delegation_payment", "label": "(b) exact execution, once", "shape": "b",
               "terms": { "payer": "0x…", "payee": "0x…", "token": "0x…", "amount": "…" },
               "cite": { "chainId": 8453, "block": "…", "tx": "0x…", "logIndex": 0 },
               "reproduce": "cast receipt 0x… --rpc-url \"$BASE_RPC_URL\" --json | jq …" } ],
  "selfDealing": null, "exposure": null,
  "cShare": { "chainId": 8453, "asOfBlock": "53160200",
              "byToken": { "0x…": { "count": { "c": 0, "total": 1 }, "value": { "c": "0", "total": "…" } } } },
  "notes": [ "no Agent Credit Lines lender registered on this chain",
             "SpendPermissionManager permissions and spends for this address: nothing indexed (blocks 53160000..53160200)" ] }

• facts：レコードエントリー、ボルトへの支払い、支出権限、委任、支払い、償還、クレジットラインの各イベントにつき1件です。それぞれのソースを示し、権限ラベル、ブロック、トランザクション、ログのインデックス、および任意の RPC から同じログを取得する1行コマンドを含みます。
• selfDealing（NablaZ アカウントのみ）：支払い先となった一意の相手先、同じコントローラーの管理下にあるアカウントへの支払い額の割合、レコードのない相手先への支払い額の割合、および「別のキーを使い、同じ人物が管理する受取人は、チェーンデータから検出できません。」という文です。
• exposure（NablaZ アカウントのみ）：許可ごと、トークンごとの、各期間における残りの許可額の最小値とボルト残高です。ただし、未処理の承認はオンチェーンで確認できません。
• cShare：トークンごとの、この読み取りに含まれる (c) ラベル付き支払い facts の件数と金額です。トークンをまたいで合算することはありません。
• notes：結果がなかったすべてのソース（「インデックス済みのデータはありません（ブロック X..Y）」、またはインデクサーがソースの開始位置に達していない場合は「X までインデックス済み。ソースは Y から開始」）、および判定不能なすべての事実をテキストで示します。

権限ラベルには、次の5つの形式があります。

形式	ラベル	由来
(a)	期間あたり／合計／呼び出しあたり／実行あたり／ストリーミングの許可額	Coinbase の支出権限、MetaMask の金額エンフォーサー、NablaZ CAM V4 のウィンドウ（正規の NablaZ アカウントでは「設計上、マンダートの範囲内」）
(b)	正確な実行、1回／N回／回数に上限なし	MetaMask の正確な呼び出しエンフォーサー、LimitedCallsEnforcer または単回使用エンフォーサーの回数
(c)	判定不能	ベンダーのリストにないエンフォーサー、デコードできない規約、正規でない NablaZ アカウント
(d)	金額または呼び出し回数の上限なし	制約が呼び出しまたは償還者のみを制限する委任
(e)	サードパーティーによる証明、ライター名を表示	Agent Credit Lines、別のライターが登録したレコードエントリー、評価者名を表示する ERC-8004 フィードバック

MetaMask のエンフォーサーテーブルは、固定コミットのベンダーの Deployments.md から生成されます（scripts/gen-enforcers.ts、src/generated/enforcers.json）。ベンダーのメインブランチにテーブルにないエンフォーサーが記載されると、テストは失敗します。

1行コマンドが信頼できる情報源です。 リーダーはログを便利に参照するためのものです。各 reproduce フィールドには、$ARB_ONE_RPC_URL または $BASE_RPC_URL に RPC URL を指定して自分で実行できる cast コマンドが含まれています。

フィードバックの根拠付け

対象が agentWallet または ERC-8004 の agentId の所有者である場合、その agentId に関するすべての NewFeedback は erc8004:feedback_grounding の事実になります（R-D2B-2）。フィードバックの根拠があるとみなされるのは、そのフィードバックより前に、評価者からアイデンティティの支払いアドレスへの ERC-20 Transfer が決済されている場合です（ブロック順、その後ブロック内のログインデックス順）。トークンや経路は問いません（R-S191-11）。支払いアドレスは送金時のブロックで解決し、それ以降の時点では解決しません。そのブロックで getAgentWallet を確認し、なければ ownerOf を確認します。また、どちらの紐付けが適用されたかを事実に記載します（R-S191-16）。アイデンティティが存在する前に行われた送金には根拠がありません（「支払いブロック時点でアイデンティティは存在しません」）。フィードバックの根拠の横には、フィードバック時のウォレットを記載します（「wallet at feedback:

」または「wallet at feedback: cleared」）。これは判定には使いません（R-S191-12）。

通常の送金はインデックス化されません。読み取り時に、読み取り側は topic0 = Transfer、topic1 = 評価者として eth_getLogs を呼び出します。トークンアドレスは問わず、Identity Registry の開始ブロック（またはインスタンスの開始ブロック）からフィードバックのブロックまでを指定し、その範囲を事実に記載します。候補となるのは、アイデンティティの agentWallet 履歴（MetadataSet）と所有者履歴（ERC-721 Transfer）にあるアドレスで、それぞれ送金時のブロックで確認します。評価者自身の被付与者ボールトからの決済は、評価者からの支払いとして扱います（R-S191-17）。ネイティブトークンの送金は読み取りません（「native-token transfers not read」、R-S191-18）。読み取り側の支払い事実のいずれかに該当する送金は、その権限ラベルを維持します。それ以外は、理由を「direct transfer, no permission object」として (c) とラベル付けされます。また、その事実には、評価者が対象者本人かどうか、および両者が NablaZ アカウントである場合は同じコントローラーを共有しているかどうかも記載されます。金額、小数桁数、タグ、URI は含まれず、フィードバックファイルも取得されません（「feedbackURI not read」）。

test/fork/afg.fork.test.ts は、Agentic Finance Graph の Base フィクスチャ（CC BY 4.0、NOTICE を参照）にある、根拠が確認された 816 件のフィードバックエントリーについて、この根拠付けを実行し、比較結果を docs/reader/afg-agreement-2026-10-20.csv に書き込みます。残る不一致については docs/reader/retroactive-binding-2026-10.md に説明があります。

ホスト型読み取り

https://read.nablaz.io は、以下の読み取り機能と MCP サーバーを1つのインスタンスとして、両方のホームチェーン（チェーン ID 42161 と 8453）で実行し、すべてのソースをデプロイブロックからインデックス化します。キーは不要で、読み取り専用です。入口は2つあります。

• GET https://read.nablaz.io/read/:chainId/:address：ローカルの GET /read が返す JSON です。
• POST https://read.nablaz.io/mcp：MCP サーバーの Streamable HTTP トランスポートで、ツールは read_subject の1つです。URL を指定する MCP クライアント向けの設定は { "type": "http", "url": "https://read.nablaz.io/mcp" } です。

どちらの入口もクライアント IP ごとにレート制限されます。制限を超えたリクエストには、プレーンテキストの本文とともに 429 が返されます。これらに加え、GET /live（プロセスが稼働中）はステータスコードと短いテキストを返し、GET /ready（インデックスが追いついている）は準備完了時に HTTP 200 と空の本文を、未準備時に 503 と {"ready":false} を返します。これ以外は何も提供しません。ステータス、メトリクス、件数のエンドポイントはありません。読み取りはインデックス化されたブロック時点で行われ、コントラクト自身のログと状態を引用するため、各事実は利用者自身の RPC に対する1行のコマンドで確認できます。デプロイには fly.toml、Dockerfile、scripts/reader-start.sh を使用します。docs/runbooks/hosted-read.md には、読み取る変数、2つのヘルスチェック用パス、データベースのバックアップスケジュールが記載されています。

Claude からホスト型リーダーを使う

NablaZ のオープンレコードを読み取ります。権限に基づくエージェントの操作を、オンチェーンの引用付きで確認できます。これは証拠であり、判定ではありません。

セットアップ。 Claude で、Settings → Connectors → Add custom connector → https://read.nablaz.io/mcp → No sign-in の順に選択します （このサーバーではキーは不要です）。同じ読み取りは、通常の HTTP でも利用できます。 GET https://read.nablaz.io/read/{chainId}/{address}。

例。

例 1 — 対象のレコードを読み取る。 プロンプト：「NablaZ Reader を使って、chain 42161 上の 0x8E65fa412e14c1859a9a278fdEFDE89A3c15b11c のレコードには何がありますか？」 動作：read_subject が GET /read/42161/<address> を呼び出し、そのアカウントについてインデックス化された事実を返します。 各事実には、それぞれのブロック番号とトランザクションの引用が付いています。また、支払いには両方の情報、つまり承認エントリーと決済トランザクションが引用されます。

例 2 — 各支払いの権限。 プロンプト：「それぞれの支払いは、どの権限に基づいて行われましたか？」 動作：各支払いの事実には、条件の形式（厳密な実行、許容量、上限なし、判定不能、第三者による証明）に基づく権限ラベルと、権限システムを示すソースラベルが付いています。

例 3 — レコードがない対象。 プロンプト：「chain 42161 上の 0x0000000000000000000000000000000000051900 のレコードには何がありますか？」 動作：リーダーは「インデックス化された情報はありません」と、対象としているブロック範囲をあわせて回答します。空の読み取り結果にも対象範囲が示され、情報が存在しないとは断定しません。

プライバシー。 リーダーではキーは不要で、ユーザーアカウントも保持しません。公開オンチェーンデータを提供し、サービスの運用に必要な情報のみをログに記録します。ポリシー全文：https://nablaz.io/privacy

サポート。 このリポジトリの GitHub の issue、または [email protected] までお問い合わせください。

ローカルで実行する

以下はすべて、ご使用のマシン上で実行されます。リーダー、MCP サーバー、スキルが含まれます。Node 22.12+ と pnpm が必要です。クリーンなチェックアウトから実行します。

pnpm install --frozen-lockfile
export READER_ARBITRUM_RPC_URL=...             # Arbitrum One RPC; archive for the envelope and exposure reads
export READER_ARBITRUM_GROUNDING_RPC_URL=...   # Arbitrum One RPC for backfill eth_getLogs and grounding reads
export READER_BASE_RPC_URL=...                 # Base RPC
export READER_BASE_GROUNDING_RPC_URL=...       # Base RPC for backfill eth_getLogs and grounding reads
export PONDER_TELEMETRY_DISABLED=true
export READER_EXTERNAL_FROM=42161:518780000,8453:53160000   # optional; see below
pnpm reader                          # = cd packages/reader && pnpm start --schema reader

各チェーンには、役割ごとに 1 つずつ、2 つの RPC URL が必要です。両方とも必須ですが、1 つの URL で両方の役割を担うこともできます。 1 つ目はヘッドの追跡と状態の読み取りに使用します。2 つ目は、ブロック範囲に対するすべての eth_getLogs（バックフィルと根拠の読み取り）に使用するため、範囲に制限がないものを指定してください。ヘッド追跡の呼び出しは、1 つ目の URL が失敗した場合にのみ 2 つ目へフォールバックします。根拠の読み取りでは、1 つ目は使用されません。

リーダーは localhost:42069 で起動します。/ready が 200 を返した時点で同期が完了し、読み取りはインデックス化済みのブロックを対象に行われます。

curl localhost:42069/ready
curl localhost:42069/read/42161/0x8E65fa412e14c1859a9a278fdEFDE89A3c15b11c

テーブルは、packages/reader/.ponder/ にあるローカルの PGlite データベースに保存されます。RPC URL は環境からのみ読み込まれ、リポジトリには書き込まれません。上記の READER_EXTERNAL_FROM の行を指定した場合、初回実行では両方のチェーンの同期完了まで約 10 分かかりました（2026 年 10 月 27 日時点）。

サードパーティのソースは、それぞれのデプロイ時点から開始するため、数年分の履歴があります。 READER_EXTERNAL_FROM を指定すると、チェーンごとに開始時点を後ろに設定できます。そのブロックより前の事実はインデックス化されず、各読み取りの注記に対象範囲が記載されます。READER_CHAINS=8453 を指定するとインスタンスを 1 つのチェーンに限定できます。READER_SOURCES=external（または nabla）を指定すると、1 つのソースグループに限定できます。

MCP サーバー

packages/mcp は MCP サーバーです。デフォルトでは stdio で動作し、read_subject（chainId、address）という 1 つのツールを提供します。リーダーに対して GET /read/:chainId/:address を呼び出し、チェーン名と基準ブロックを示す行に続けて、JSON を変更せずに返します。読み取り専用で、書き込みや署名のツールはなく、キーも保持しません。リーダーの URL は --reader-url または NABLAZ_READER_URL から取得し、デフォルトは http://localhost:42069 です。

pnpm --silent mcp                    # = cd packages/mcp && pnpm start

stdout はプロトコルに使用されるため、最初に stdout へ何かを出力するものを使わずに起動してください（--silent なしで pnpm を実行すると、バナーが表示されます）。stdio サーバーを JSON 設定から起動する MCP クライアントの場合：

{
  "mcpServers": {
    "nablaz-read": {
      "command": "node",
      "args": ["--experimental-strip-types", "--disable-warning=ExperimentalWarning", "/path/to/nablaz-sdk/packages/mcp/src/main.ts"],
      "env": { "NABLAZ_READER_URL": "http://localhost:42069" }
    }
  }
}

HTTP トランスポート

--transport http を指定すると、同じサーバーを Streamable HTTP で POST /mcp から利用できます。ツールは同じ read_subject の1つだけです。ステートレスで、セッションもキーもなく、書き込みや署名の経路もありません。ポートは --port または PORT で指定します（デフォルトは3042）。クライアント IP ごとにプロセス内でリクエスト数が制限され、上限は1分あたり MCP_RATE_LIMIT_PER_MIN（デフォルトは60）です。上限を超えたリクエストには、プレーンテキストの本文とともに429を返します。クライアント IP はソケットのピアです。ただし、前段のプロキシが上書きするヘッダーを MCP_CLIENT_IP_HEADER に指定した場合は、そのヘッダーの値が使われます（例：X-Real-IP）。プロキシが必ず設定するヘッダーだけを指定してください。クライアントが送信できるヘッダーは、クライアントが偽装できるヘッダーです。GET /read/:chainId/:address と GET /ready は同じ制限のもとでリーダーに中継されるため、1つのポートで両方の入口を提供できます。500未満のレスポンスは変更せずに返します。/ready が503の場合は {"ready":false} を返し、それ以外の5xxの場合は {"error":"internal error"} を返します。リーダーの本文は、前段のログにのみ記録されます。GET /live は、前段が稼働中でリーダープロセスが応答している間は200を返し、そうでない場合は、インデックスの進捗にかかわらず503を返します。CORS ヘッダーや件数・メトリクスのエンドポイントはありません。それ以外のパスには404を返します。

pnpm --silent mcp -- --transport http --port 3042

リーダーと HTTP MCP サーバーを1つのインスタンスとして、全履歴を対象に同時に実行するには、次の環境設定を使用します。両方のチェーンを読み取り、各ソースはデプロイブロックから開始します。

READER_ARBITRUM_RPC_URL=...             # Arbitrum One RPC, archive: head tracking and state reads
READER_ARBITRUM_GROUNDING_RPC_URL=...   # Arbitrum One RPC, archive, unlimited eth_getLogs range
READER_BASE_RPC_URL=...                 # Base RPC, archive
READER_BASE_GROUNDING_RPC_URL=...       # Base RPC, archive, unlimited eth_getLogs range
PONDER_TELEMETRY_DISABLED=true
NABLAZ_READER_URL=http://localhost:42069
PORT=3042
MCP_RATE_LIMIT_PER_MIN=60
MCP_CLIENT_IP_HEADER=                # the client-IP header the proxy in front overwrites; unset without one

READER_EXTERNAL_FROM、READER_CHAINS、READER_SOURCES、READER_START_BLOCK は設定しないでください。

フィードバックの根拠と (c) の割合をローカルで確認する

ERC-8004 ソースはサードパーティのグループに含まれているため、上記の実行ではインデックス化されます。READER_EXTERNAL_FROM を設定すると、他のサードパーティソースと同じブロックから開始します。そのブロックより前に設定された agentWallet は認識されず、読み取り結果にはインデックス化されたデータがないと表示されます。その場合は、次のようにします。

curl localhost:42069/read/8453/<agentWallet>   # grounding facts, cShare, notes

インデックス全体における、ブロック範囲ごとのトークン別の (c) とラベル付けされた支払い事実の割合です（スクリプトがデータベースを開くため、先にリーダーを停止してください）。

pnpm report:c-share 8453 53160000 53160200   # READER_PGLITE_DIR defaults to packages/reader/.ponder/pglite

入力内容とトークンごとの1行、件数を再現する SQL が出力されます。Arbitrum One の Vault 支払いはアカウントを通じてラベル付けされます。そのため、READER_ARBITRUM_RPC_URL が必要です。

スキル

skills/read-record/SKILL.md では、ツールまたは GET /read の呼び出し方、各ソースとラベルの形式、リーダーが決して述べない内容を説明しています。skills/pay-inside-grant/SKILL.md では、被付与者の Vault から支払う方法を説明しています。

テスト

pnpm typecheck
pnpm test          # unit
pnpm test:fork     # needs anvil and cast (Foundry) and the RPC variables below
NABLAZ_PROTOCOL_DIR=/path/to/nablaz-protocol pnpm test   # also checks the lineage copy against nablaz-protocol

リーダーのフォークテストでは、READER_ARBITRUM_RPC_URL（アーカイブ）、READER_BASE_RPC_URL と2つの *_GROUNDING_RPC_URL を読み取ります。packages/sdk の読み取りテストでは READER_ARB_RPC_URL（アーカイブ）を読み取ります。

フォークテストでは、Arbitrum One の anvil フォークを実行し、abis/ の ABI を使って TypeScript から稼働中のコントラクトを操作します。その結果を最初からインデックス化し、導出された行を検証します。インデックス化を2回行い、テーブルが同一であることを確認します。別のテストでは、最初のアカウントの直前のブロックまで Arbitrum One をインデックス化し、すべてのテーブルが空になることを確認します。両方のチェーンで、3つ目のテストは固定期間のサードパーティソースをインデックス化します。ソースごとに、レンダリングした1行コマンドを cast 経由で実行し、リーダーの行数と一致することを確認して、サンプル対象の償還のうち「判定不能」とラベル付けされた割合を出力します。アカウント被付与者のテストでは、稼働中のファクトリーに NablaAccount を作成し、TEST アカウント上の助成金の被付与者に設定して、被付与者の署名が PersonalSign 形式の x402 支払いを1件決済します。MCP テストでは、配信中のリーダーに対して stdio サーバーを実行し、その出力を GET /read と比較します。

x402

依存関係の最低バージョンは @x402/* ≥ 2.23.0 です。これは10月22日の V12 開示で指摘された問題（クライアントにデフォルトの支出上限がないこと）の修正を含むバージョンです。このリポジトリでは packages/sdk/package.json でバージョン（2.28.0）を固定しています。支払い上限はクライアントではなく、アカウント内の助成金エンベロープによって適用されます。

出典

コントラクトアドレス（src/generated/addresses.ts）と ABI（abis/*.json）は、固定された nablaz-protocol のコミットから生成されます。各生成ファイルのヘッダーにはコミットが記録されています。読み取り側の currentAccountImpl の系譜、ブートストラップ、ProtocolConfig（packages/reader/src/generated/account-lineage.json）は、ファイル名で指定されたコミットおよび blob にある script/expected/permanent-arbitrum.txt からコピーされています（packages/reader/scripts/gen-lineage.ts）。ここから取得するのはアドレスと ABI のみです。どちらもオンチェーンで公開されています。

ライセンス

MIT です。LICENSE をご覧ください。