Elara Verify

The problem

Agents are starting to act on our behalf: booking, buying, filing, approving. Every one of those actions produces a claim — "I was authorized to do this" — and today the only way to check a claim like that is to ask whoever made it. That is not verification. That is trust with extra steps.

What this does

This site exposes a cryptographic verifier as WebMCP tools, so an agent browsing the page can hand over a record or an authorization bundle and get back a real verdict:

• verify_elara_record — is this signed action record intact, and who signed it? Post-quantum signature check (ML-DSA-65, FIPS 204), structure, identity binding.
• verify_mandate_bundle — was the agent actually authorized for the act it performed, under a scoped, revocable mandate?
• explain_verdict — states in plain language what the verdict does and, just as importantly, does not claim.

The verification runs in the browser, in WebAssembly compiled from the same open-source code that is published on crates.io. Your bytes and the verdict never touch the network: the demo samples are pre-loaded with the page, so after load it makes no further network calls — turn off your wifi and it still works.

Why WebMCP is the right primitive for this — not just a convenient one

Most WebMCP tools make a website easier for an agent to use. This one exists because the alternative is meaningless.

If an agent asks a server "is this evidence valid?", the answer is worth exactly as much as the server is trusted. The agent hasn't verified anything; it has moved its trust from one party to another. A verification service is a strange product: the moment you have to trust it, it has failed at its job.

WebMCP dissolves that. The tool executes in the agent's own browser, over bytes the agent already holds, using WASM that anyone can rebuild from public source and diff against what we serve. There is no server in the trust path because there is no server in the path at all. For a trust primitive, in-browser tool execution isn't an optimization — it's the only architecture in which the answer means anything.

That is also why the tools are pure functions: input bytes in, verdict out. Nothing is written, stored, or transmitted, and deliberately nothing signs, issues, or revokes. A signing tool on a public page would hand any passing agent our identity. The verifier can only ever tell you what is already true about bytes you brought.

What it's honest about

A verdict here proves integrity and signer — that these exact bytes were signed by this key. It is not a claim that anything is "on a chain", and a bundle cannot reveal a revocation its author chose to withhold. The tool descriptions say so themselves, because the agent reads those, not our README. The underlying evidence log is a signed, hash-linked record chain in a published open format — not a blockchain.

We would rather a judge learn the limits from us than discover them.

Try to break it

Load any record, verify it, then change one character of its content and verify again. The tampered record fails and names itself. That's the whole product in one gesture: don't trust the demo — verify it.

What's new here vs. what existed

The verifier, the record format, and the crates are pre-existing open-source work — first published on crates.io on 2026-07-18 and actively maintained since (the versions this page runs: elara-record 0.3.0 and elara-verify 0.3.3, released Aug 23–25, both MIT OR Apache-2.0, built in the open in this repository). The WebMCP tool layer is new, written after the submission period opened on Aug 25, and the repository's dated commit history is the evidence — as the rules provide for projects that existed beforehand and were meaningfully extended with WebMCP.

The tool layer has already earned one honest scar: while building its test harness we found that JavaScript's JSON.parse silently rounds the format's u64 fields (they exceed 2^53), which had made our own demo misreport a valid sample for weeks. The fix (commit fe8bcc71, Aug 29) moved the whole surface to raw-text end-to-end, and the tools now reject pre-parsed input with an explanation instead of returning a confident verdict on corrupted bytes — exactly the behavior you want from a verifier that would rather refuse than be plausibly wrong.

Nothing about that layer is a wrapper for its own sake: it is the first time this verifier has been reachable by an agent rather than only by a human clicking a button.

Who built it

Entrant of record: Nenad Vasic — also the publisher of the crates above. The project's ongoing open-source maintenance is performed by an AI agent operating under his receipted, revocable, scope-limited mandate. The mandate mechanism that governs that arrangement is the same one verify_mandate_bundle checks. We didn't build a demo of agent accountability; we've been living under one, and this is us handing you the tool to audit it.

Built With

• cryptography
• fips-204
• github
• javascript
• ml-dsa
• model-context-protocol
• rust
• wasm
• webassembly
• webmcp