An isolated Cloudflare Tunnel test on October 11 confirmed hybrid key exchange at the connector and verified that a request through the tunnel could reach the existing API health endpoint.
The test connector ran cloudflared on Railway. Both the test client-to-Cloudflare connection and the Cloudflare-to-connector connection negotiated X25519MLKEM768 with certificate verification. The connector used QUIC/TLS 1.3.
The API health response returned HTTP 200 with the same randomly generated request ID, confirming that the request reached the API. The temporary test service was removed after measurement.
In production, new x402 observations, transparency-log tree heads, Service Receipt v2 and hosted Apostille Core 0.3 use ML-DSA-65 signatures. New database backups use AES-256 with file keys wrapped by ML-KEM-768 + X25519; a real backup and an isolated PostgreSQL restore passed on October 10.
Measured scope
The Tunnel result comes from an isolated test; production routing remains unchanged. The final connector-to-API hop used private-network HTTP. The measured hybrid key exchange does not establish post-quantum certificate authentication or encryption across the entire path.
New x402 monitor reports and signed tree heads, Service Receipt v2 and hosted Apostille Core 0.3 now use ML-DSA-65 signatures. Historical Ed25519 records remain verifiable under their original, classical algorithm.
On October 10, production backups switched to ML-KEM-768 + X25519 wrapping for new backup file keys. A real backup and an isolated restore drill both passed. Historical backups were not changed.
On October 10 (Taipei time), our test client negotiated X25519MLKEM768 with the Cloudflare endpoint for ifandonlyif.io, with certificate verification enabled. Other clients may negotiate differently.
What these changes establish
This is progress in specific layers, not a claim that the whole system is post-quantum. Wallet and chain cryptography and Groth16 are unchanged. Signatures do not prove content truth or prevent compromise of signing keys or hardware.
New x402 monitor reports, transparency-log tree heads and Service Receipts are signed with ML-DSA-65 (FIPS 204). Hosted Apostille now issues Core 0.3 only, and the Apostille SDK and CLI v0.4.0-alpha.1 create ML-DSA-65 keys by default. Earlier Ed25519 signatures remain verifiable history.
Pin the new keys from the reviewed copies in the public repositories, not from an API response.
What stays classical
Ethereum wallet consent and on-chain anchoring use secp256k1. Existing Core 0.1 workspaces are read-only. A signature records who signed which bytes; it does not show that an endpoint or artifact is safe.
The supply-chain API preview adds seven routes to register release evidence, set receiver policies, evaluate metadata and withdraw a release. At introduction, it supported existing Core 0.1 or Core 0.3 certificates within your workspace; the hosted signing rollout subsequently made Core 0.1 workspaces read-only. Pin issuer and producer keys in your own policy; keys inside a bundle or directory are not trusted automatically.
Before integrating, check GET /api/apostille/v1/status: enabled must be true and features must include supply_chain_releases.
What this check establishes
A policy result combines signed evidence, submitted metadata and a current hosted observation. The API never inspects file bytes, so compare the file's hash and size with the signed manifest yourself. This is not malware scanning, and a valid signature does not mean an artifact is safe.
The alpha.2 source preview of Apostille Local adds an Anthropic Messages API subset (POST /v1/messages: text, streaming, custom tool use, JSON Schema output) beside OpenAI Chat Completions. It runs the local model your administrator enables, provides no Claude weights and never calls Anthropic cloud services.
A generic CLI and SDK also record signed workflow metadata, with an optional Flower example. The gateway does not save prompts or answers by default. Not yet published to a package registry; Apostille Core 0.1 is unchanged.
What the records establish
Receivers verify them offline with independently obtained key pins and their own policy. Records do not establish answer correctness, actual model execution or that data never left an environment.
The IFF and Apostille sign-in service was updated. Reload and sign in again with your existing identity. API clients that receive 401 Unauthorized must complete sign-in again and store the new session credentials. Workspaces and records are preserved.
Apostille Core 0.1 Go SDK and CLI are installable as v0.1.0-alpha.1; the hosted service uses the same release.
go get github.com/ifandonlyif-io/iff-apostille@v0.1.0-alpha.1
go install github.com/ifandonlyif-io/iff-apostille/cmd/apostille@v0.1.0-alpha.1
The later Core 0.3 (ML-DSA-65) release was v0.3.0-alpha.1 (client v0.3.1-alpha.1). At that stage, the hosted service issued both Core 0.1 and 0.3 with published issuer pins, and Core 0.1 remained the signing default. Only Core 0.3 signatures are post-quantum. See the October 10 signing switch for the current behavior.
Offline verification checks signatures and byte bindings. Trust needs an independently chosen issuer and key pin; it does not establish content truth or legal identity.
Anonymous HTTP MCP alpha: 13 read-only IFF tools at /mcp/iff and seven read-only Apostille tools at /mcp/apostille. No account, OAuth, key or original file is needed, and the IFF tools never execute payment.
Apostille trust comes only from the issuer/key pins you supply, and verification runs on the hosted service, so a result is not independent evidence about IFF.
Two local stdio Go MCP servers entered internal alpha: iff-mcp (14 IFF evidence and log tools, no payments) and apostille-mcp (20 tools; offline verification by default, optional authorized signing and submission).
Neither is publicly distributed or hosted, and neither is part of @ifandonlyif/x402-preflight, whose single verify_x402_endpoint tool is unchanged.
Optional Apostille profiles add private ERC-8004 agent identity bindings and experimental local ZK budget proofs. They do not feed the IFF x402 monitor, anchor or reputation.
Offline verification needs an exact issuer and key pin; token ownership does not establish organization identity, endpoint control or payment authority. A ZK proof shows that a signed vector of 1–16 amounts sums to at most the receiver's limit, in a local single-party development setup.
Apostille Core 0.1 alpha lets you sign bot artifacts locally and recipients verify bundles offline. IFF receives the signed manifest, not the original file, and publishing needs an explicit PublicationGrant. It is isolated from IFF x402 evidence cards, monitor observations, webhooks and transparency logs.
Trust needs an independently obtained issuer URI and key fingerprint pin. A valid bundle does not prove content truth, organization identity, TEE execution or current revocation status.
The homepage, guides, API docs, SDK guide and updates are available in English, Japanese, Traditional Chinese and Simplified Chinese. Technical terms, API names and code keep their original text; the receipt verifier is English only.
Receipt results now clear or expire with your input and the clock. Endpoint owners can list several ownership claims in one file with a claims list; keep existing claims when adding one, and each endpoint still needs its own matching challenge.
Live lookup now offers Submit for monitoring for unrecorded URLs and Check progress for submissions. The BSC example and Naven's Robinhood Chain Ping resource have public observed-tier cards; ownership is unverified and 0G public-network acceptance is incomplete.
Browser and server receipt checks now apply the same input, issuer and timestamp rules, and key-directory refreshes recover from temporary outages. Only the robots.txt fetch follows validated redirects; endpoint probes still do not.
A directory match recognizes a key; independent trust still needs the exact issuer and a separately obtained full key fingerprint.
A browser verifier for IFF's optional signed Service Receipt envelopes. Paste or load receipt JSON; parsing and signature checks run locally, and issuer recognition may fetch the public key directory. API callers opt in; ordinary preflight responses are unchanged.
Scope of this feature
Not an x402 payment receipt. It does not prove payment, service delivery, caller identity, remote execution, result correctness or safety.