
Akashi Notari
io.github.self-realityv1.1.0更新於 Oct 6, 2026
Proof of existence for files: anchor a SHA-256 hash on Base, look up proofs. Paid with x402.
概覽
讓助理在 Base 上為檔案的 SHA-256 雜湊付費錨定,並查詢既有的存在證明。
- 功能
- 透過 Streamable HTTP 提供兩個 MCP 工具:find_proof 接受雜湊或交易雜湊,回傳該雜湊是否已錨定及其第一筆證明;anchor_hash 接受雜湊與可選檔名,在鏈上寫入證明(R12、R36、R37)。付費工具遵循 x402 MCP 傳輸:未付款時回傳 PaymentRequired 物件,用戶端簽署後結果會帶有證明與結算資訊(R39、R40)。同一服務也可透過一般 HTTP 端點進行錨定與證明查詢(R6、R8、R10)。
- 適用情境
- 當你需要可驗證、帶時間戳地證明某個檔案在某個時刻已存在,或想查詢某個 SHA-256 雜湊是否已在 Base 上錨定時使用。它適合能透過 x402 自動支付小額 USDC 的助理。它不用於一般檔案儲存或內容取得,因為只記錄雜湊與可選檔名。
- 執行需求
- 遠端 Streamable HTTP 端點 需要支援 x402 的用戶端,以及可簽署支付 USDC 的 Base 錢包(R26、R23);find_proof 免費。自行部署此 Worker 需要 Node.js 與 pnpm、Cloudflare Workers 環境、帶 ETH 的中繼錢包金鑰、註冊表合約位址,最好還有帶金鑰的 RPC 端點(R62、R68、R71、R74、R87、R89)。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Akashi Notari,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。
其他 MCP 客戶端
把它新增到你客戶端的 mcpServers 設定中。
{
"mcpServers": {
"akashi-notari": {
"type": "http",
"url": "https://anchor.akashi-notari.com/mcp"
}
}
}README
Anchor Worker
Cloudflare Worker that sells anchors to agents over x402. An agent sends a SHA-256 file hash and a signed USDC payment in one HTTP request; the worker sends one transaction to VerifierRegistryUSDC, which takes the USDC and writes the proof. No facilitator is involved.
API Endpoints
POST /anchor→ paid. Writes the hash on-chain, returns the transaction hash and a certificate linkGET /proof?hash=<sha256 hex>→ free. Whether this hash is anchored, and its first proofGET /proof?tx=<transaction hash>→ free. The proof written by this transactionPOST /mcp→ MCP server (Streamable HTTP) with the toolsfind_proofandanchor_hashGET /openapi.json→ OpenAPI description; directories such as x402scan read it before they register/anchorGET /.well-known/x402→ x402 discovery document listing/anchorGET /.well-known/agent-registration.json→ ERC-8004 agent registration fileGET /llms.txt→ the service described for language modelsGET /→ service description and current priceGET /health→{ ok: true }
POST /anchor
Body: { "hash": "<sha256, 64 hex chars>", "filename": "<optional>" }. A 0x prefix and uppercase are accepted; the hash is stored lowercase without 0x, the same form the web app writes. The filename follows the web app's rules: lowercase a-z 0-9 - _ ., at most 128 characters.
Without a PAYMENT-SIGNATURE header the worker answers 402 with the terms in a PAYMENT-REQUIRED header (x402 v2, base64 JSON) and the same JSON in the body:
The amount is read from price() on the contract, so the quote and the contract always agree. With a valid payment the response is 200 and carries a PAYMENT-RESPONSE header:
Any x402 client works:
GET /proof
VerifierRegistryUSDC stores the first anchor of each hash, so a lookup by hash is one contract read (firstAnchor) and a log query on the one block it names. No search over the chain and no explorer key is needed.
proofsholds the first anchor of the hash onVerifierRegistryUSDC. Later anchors of the same hash exist as events and open with?tx=- The ETH
VerifierRegistrythe web app writes to stores nothing, so its proofs need an explorer API. When that search fails, the contract moves fromsearchedtounsearchedand the rest of the answer still stands.anchored: falsewith anunsearchedentry means "not found where we could look"
MCP
POST /mcp speaks MCP over Streamable HTTP, without sessions: every request stands alone, and GET returns 405.
find_proof{ hash }or{ tx }: free, the same answer asGET /proofanchor_hash{ hash, filename? }: paid, following the x402 MCP transport. Without a payment the result is a tool error whosestructuredContentis the x402PaymentRequiredobject. The client signs it and calls again with the payment inparams._meta["x402/payment"]; the result then carries the proof, and the settlement in_meta["x402/payment-response"]
server.json in this folder describes the server for the MCP registry.
Status Codes
400bad hash, filename or payment header. Checked before the payment is touched; nothing is charged402no payment, or the payment cannot be settled. The body'serroris an x402 error code such asinsufficient_funds409payment_already_used: this authorization already bought an anchor. Look it up with/proof503the worker has no contract address or relayer key
Notes
- The transaction either moves the USDC and emits the proof, or reverts and moves nothing
- The response has
status: "confirmed"with the full proof once the transaction is mined. If no RPC endpoint reports it within 30 seconds the response is still200, withstatus: "submitted", thetxHashand alookupURL. A payment that was broadcast is never reported as failed - The on-chain
submitteris the payer, not the relayer - If an authorization was already executed on the token (by a facilitator, or by someone who front-ran the relayer), the worker confirms the transfer to the contract in the token's logs and anchors it with
anchorPaid. It looks back 1,800 blocks - A canceled authorization buys nothing
- The official x402 client refuses payments above $1 unless its user raises the limit; keep the price at or below $1 for agents to pay without configuration
- Concurrent requests share one relayer key. A colliding nonce is retried three times; heavy traffic needs a queue
- Public RPC nodes and the keyless Blockscout API refuse or rate-limit requests from Cloudflare's shared addresses. In production set
RPC_URLto a keyed endpoint as a secret.LOGS_API_KEYis only needed to include the ETH contract's proofs in/proof?hash= - The recovery of an authorization executed on the token searches 1,800 blocks of token logs, which a free Alchemy key refuses (10 blocks). List a second endpoint in
RPC_URLor use a paid key to keep that path working - Rate limited to
RATE_LIMIT_PER_MINrequests per IP (default 60)
Environment Variables
RELAYER_PRIVATE_KEY: secret. The wallet that sends the transactions. It needs ETH for gas andsetRelayer(address, true)on the contractREGISTRY_ADDRESS: the deployedVerifierRegistryUSDCCHAIN_ID:8453(Base, default) or84532(Base Sepolia). These two have built-in defaults for everything belowRPC_URL: one or more RPC endpoints, comma-separated, tried in order. The default for Base is a list of public nodes; set a keyed endpoint (Alchemy, Infura) as a secret for production trafficRPC_ORIGIN: sent as theOriginheader on RPC calls, for a provider key restricted to an origin allowlistTOKEN_ADDRESS,TOKEN_NAME,TOKEN_VERSION,EXPLORER_URL: optional overrides.TOKEN_NAMEandTOKEN_VERSIONare the token's EIP-712 domainLEGACY_REGISTRY_ADDRESS: the ETHVerifierRegistry, included in lookupsLOGS_API_URL,LOGS_API_KEY,LOGS_FROM_BLOCK: Blockscout-compatible logs API that searches the ETH contract for/proof?hash=, and an optional API key for it. SetLOGS_API_URLempty to use the RPC nodeAGENT_REGISTRATIONS: JSON array for theregistrationsfield of the agent registration file, e.g.[{"agentId":22,"agentRegistry":"eip155:8453:0x…"}], set once the agent is registered on an ERC-8004 identity registryPUBLIC_URL: the worker's public origin, used in theresource.urlit advertisesCERTIFICATE_URL,CERTIFICATE_CHAIN: where certificate links pointRATE_LIMIT_PER_MIN: default 60
Local Development
Tests
The end-to-end script deploys a mock USDC and both registries to a local chain, then drives the worker by hand, through the official x402 client and over MCP.
Deployment
來源:workers/anchor/README.md,提交 24f490b
工具
0版本歷史
1- v1.1.0最新Oct 6, 2026


