Akashi Notari

io.github.self-realityv1.1.0Updated Oct 6, 2026

Proof of existence for files: anchor a SHA-256 hash on Base, look up proofs. Paid with x402.

VerifiedStreamable HTTPWeb executableDeveloper ToolsSecurity & MonitoringFinance

Overview

AI-generated overview

Lets an assistant anchor a file's SHA-256 hash on Base for a USDC fee and look up existing proofs of existence.

What it does
Exposes two MCP tools over Streamable HTTP: find_proof, which takes a hash or a transaction hash and returns whether that hash is anchored plus its first proof, and anchor_hash, which takes a hash and optional filename and writes a proof on-chain (R12, R36, R37). The paid tool follows the x402 MCP transport: without payment it returns a PaymentRequired object, and after the client signs, the result carries the proof and settlement metadata (R39, R40). The same service is also reachable over plain HTTP endpoints for anchoring and proof lookup (R6, R8, R10).
When to use it
Use it when you need a verifiable, timestamped record that a specific file existed at a point in time, or when you want to check whether a given SHA-256 hash has already been anchored on Base. It suits agents that can pay small USDC amounts automatically over x402. It is not needed for ordinary file storage or content retrieval, since only hashes and optional filenames are recorded.
Requirements
Remote Streamable HTTP endpoint at no local install and no declared authentication. anchor_hash requires an x402-capable client with a funded Base wallet able to sign a USDC payment (R26, R23). find_proof is free. Self-hosting the worker needs Node.js with pnpm, a Cloudflare Workers deployment, a relayer wallet key with ETH for gas, a registry contract address, and preferably a keyed RPC endpoint (R62, R68, R71, R74, R87, R89).
Before you install
anchor_hash spends real USDC on Base; the price is read from the contract and the official x402 client refuses payments above 1 USD unless the limit is raised (R58). The worker holds a relayer wallet key (RELAYER_PRIVATE_KEY) that needs ETH for gas, and concurrent requests share that one key (R59, R60). Anchoring writes the hash, optional filename and payer address permanently on a public chain (R25, R54). A canceled authorization buys nothing, and a reused authorization returns 409 (R47, R57).

Installation

In SourceWeft

  1. Open Akashi Notari in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Other MCP clients

Add this to your client's mcpServers config.

{
  "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 link
  • GET /proof?hash=<sha256 hex> → free. Whether this hash is anchored, and its first proof
  • GET /proof?tx=<transaction hash> → free. The proof written by this transaction
  • POST /mcp → MCP server (Streamable HTTP) with the tools find_proof and anchor_hash
  • GET /openapi.json → OpenAPI description; directories such as x402scan read it before they register /anchor
  • GET /.well-known/x402 → x402 discovery document listing /anchor
  • GET /.well-known/agent-registration.json → ERC-8004 agent registration file
  • GET /llms.txt → the service described for language models
  • GET / → service description and current price
  • GET /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:

json
{  "x402Version": 2,  "accepts": [    {      "scheme": "exact",      "network": "eip155:8453",      "amount": "10000",      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",      "payTo": "<VerifierRegistryUSDC>",      "maxTimeoutSeconds": 120,      "extra": { "assetTransferMethod": "eip3009", "name": "USD Coin", "version": "2" }    }  ]}

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:

json
{  "ok": true,  "status": "confirmed",  "hash": "be44340d151cbfa7a5dc59b579dd6632fb0891b573f8fdc927264309a3b168f0",  "filename": "report.pdf",  "submitter": "<payer address>",  "timestamp": 1790919801,  "timestampIso": "2026-10-02T05:43:21.000Z",  "paid": "10000",  "currency": "USDC",  "chain": "base",  "txHash": "0x...",  "explorerUrl": "https://basescan.org/tx/0x...",  "certificateUrl": "https://akashi-notari.com/certificate/?chain=base&hash=0x..."}

Any x402 client works:

js
import { wrapFetchWithPaymentFromConfig } from '@x402/fetch';import { ExactEvmScheme } from '@x402/evm';
const pay = wrapFetchWithPaymentFromConfig(fetch, {  schemes: [{ network: 'eip155:8453', client: new ExactEvmScheme(account) }],});const res = await pay('https://<worker>/anchor', {  method: 'POST',  headers: { 'content-type': 'application/json' },  body: JSON.stringify({ hash, filename: 'report.pdf' }),});

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.

json
{  "hash": "be44340d…",  "anchored": true,  "proofs": [ { "hash": "…", "filename": "report.pdf", "submitter": "0x…", "timestamp": 1790919801, "txHash": "0x…", "contract": "0x…" } ],  "searched": ["<VerifierRegistryUSDC>", "<VerifierRegistry>"]}
  • proofs holds the first anchor of the hash on VerifierRegistryUSDC. Later anchors of the same hash exist as events and open with ?tx=
  • The ETH VerifierRegistry the web app writes to stores nothing, so its proofs need an explorer API. When that search fails, the contract moves from searched to unsearched and the rest of the answer still stands. anchored: false with an unsearched entry 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 as GET /proof
  • anchor_hash { hash, filename? }: paid, following the x402 MCP transport. Without a payment the result is a tool error whose structuredContent is the x402 PaymentRequired object. The client signs it and calls again with the payment in params._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

  • 400 bad hash, filename or payment header. Checked before the payment is touched; nothing is charged
  • 402 no payment, or the payment cannot be settled. The body's error is an x402 error code such as insufficient_funds
  • 409 payment_already_used: this authorization already bought an anchor. Look it up with /proof
  • 503 the 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 still 200, with status: "submitted", the txHash and a lookup URL. A payment that was broadcast is never reported as failed
  • The on-chain submitter is 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_URL to a keyed endpoint as a secret. LOGS_API_KEY is 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_URL or use a paid key to keep that path working
  • Rate limited to RATE_LIMIT_PER_MIN requests per IP (default 60)

Environment Variables

  • RELAYER_PRIVATE_KEY: secret. The wallet that sends the transactions. It needs ETH for gas and setRelayer(address, true) on the contract
  • REGISTRY_ADDRESS: the deployed VerifierRegistryUSDC
  • CHAIN_ID: 8453 (Base, default) or 84532 (Base Sepolia). These two have built-in defaults for everything below
  • RPC_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 traffic
  • RPC_ORIGIN: sent as the Origin header on RPC calls, for a provider key restricted to an origin allowlist
  • TOKEN_ADDRESS, TOKEN_NAME, TOKEN_VERSION, EXPLORER_URL: optional overrides. TOKEN_NAME and TOKEN_VERSION are the token's EIP-712 domain
  • LEGACY_REGISTRY_ADDRESS: the ETH VerifierRegistry, included in lookups
  • LOGS_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. Set LOGS_API_URL empty to use the RPC node
  • AGENT_REGISTRATIONS: JSON array for the registrations field of the agent registration file, e.g. [{"agentId":22,"agentRegistry":"eip155:8453:0x…"}], set once the agent is registered on an ERC-8004 identity registry
  • PUBLIC_URL: the worker's public origin, used in the resource.url it advertises
  • CERTIFICATE_URL, CERTIFICATE_CHAIN: where certificate links point
  • RATE_LIMIT_PER_MIN: default 60

Local Development

bash
cd workers/anchorpnpm installcp dev.vars.template .dev.varspnpm dev

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.

bash
# terminal 1cd contracts/registry && npx hardhat compile && npx hardhat node
# terminal 2cd workers/anchor && pnpm test:e2e

Deployment

bash
# 1. Deploy the contract and allow the relayer (try baseSepolia first)cd contracts/registryRELAYER_ADDRESS=0x... pnpm hardhat run scripts/deploy-usdc.js --network base
# 2. Put the address from constants-usdc.json into wrangler.toml as REGISTRY_ADDRESS
# 3. Set the relayer key and deploycd ../../workers/anchornpx wrangler secret put RELAYER_PRIVATE_KEYnpx wrangler deploy
# 4. Send the relayer a little ETH on Base for gas
# 5. Rebuild and deploy the web app, so the certificate page reads the new contract

Source: workers/anchor/README.md at commit 24f490b

Tools

0
Tool metadata has not been indexed yet.

Version history

1
  1. v1.1.0LatestOct 6, 2026