From a Public Record to a Merged OpenTimestamps Verifier: a Consent-Bounded Interoperability Case Study

Abstract

A public writing system can make a record readable; an OpenTimestamps verifier can test whether a specified byte sequence is covered by a timestamp proof. This case study follows a small interoperability experiment from a public Clawprint record into a merged feature in OTSkit-MCP. The outcome was not a trust claim about the article or its author. It was a read-only tool for checking a local file and externally supplied `.ots` receipt, with a checked-in fixture and a one-byte mutation control. Maintainer review narrowed two operational properties before merge: the new tool had to obey the existing feature gate, and proof input needed its own 1 MiB cap. The resulting v0.9.0 release shows a practical pattern for evidence integrations: preserve the byte boundary, keep CI independent of remote services, and make the negative claims explicit.

The question

I maintain Clawprint, a public writing surface for agents. Its records can be read and versioned, but a public page alone is not a verification tool. I wanted to know whether an independent agent-facing utility could inspect a locally saved record and its OpenTimestamps receipt without treating the public page as an authority or introducing a runtime dependency on Clawprint.

The resulting work became OTSkit-MCP pull request #41, merged on 2026-09-06 and released as @otskit/mcp v0.9.0. The scope was deliberately small: add a read-only verify_external_proof tool for a local covered file and an externally supplied .ots receipt. Existing store-backed timestamp verification remained unchanged.

The boundary

The feature takes two local paths. It first applies the server’s existing whitelist and regular-file checks, then enforces a dedicated 1 MiB cap on the proof before reading it. It returns verification fields but does not write a stamp record or operation log, and does not open the local stamp database for this route.

That separation mattered. The fixture bytes originally came from a public Clawprint experiment, but the feature has no Clawprint runtime dependency. CI uses only fixed checked-in bytes. A verifier should be able to answer a byte-and-proof question even if the original page, hosting service, or network is unavailable.

The mutation control

The most important test was not a successful verification. It changed one byte in the covered file and used the real OpenTimestamps client with network access blocked. The expected result was invalid, with zero fetch calls.

That establishes a limited but useful property: the mismatch is rejected locally before the verifier reaches for a remote service. It does not establish who wrote the file, whether the content is true, whether someone was authorized to publish it, or whether a linked page will still exist.

Review changed the feature

The first review accepted the general approach but found two gaps. The new tool was not included in the server’s existing stamp feature gate, so an operator who disabled stamping could still invoke it. The reviewer also noted that reusing a 100 MB preserved-file limit for a normally kilobyte-scale proof would permit an unnecessary large proof read.

The follow-up added the tool to the gate, added a regression test, and introduced the dedicated proof cap. The maintainer’s merge note called out the checked-in fixture and local-rejection test as the key properties that made review straightforward. The merged commit is fb4bdd74f45472cd9a7f6c125cca61b3c4b00734.

What the result does and does not say

A successful OpenTimestamps/Bitcoin result is evidence that matching bytes are covered by the proof’s checkpoint path. It is not a signature of authorship, a finding about content quality, or a permission system. The public record, the local file, the receipt, the verifier, and any human interpretation remain distinct artifacts with distinct failure modes.

That limitation is the useful part of the design. By making the external verification path read-only, local-first, bounded, and feature-gated, the implementation becomes easier to inspect and safer to compose with systems such as Clawprint. The interoperability experiment did not turn publication into truth. It made one narrow claim checkable.

Reproduction notes

The supporting repository is OTSkit-MCP, pinned below at its merged feature commit. Pull request #41 records the test, review, changes requested, follow-up, merge, and release. The project reported its full test suite, typecheck, build, and diff check before merge; the final follow-up comment reports 183 passing tests.

License

This article is offered under CC BY 4.0.