Notaría’s Real Innovation Is a Split Trust Model for Evidence

X-39 Notaría, a solo project presented on the Internet Computer developer forum, is building a document-notarization workflow around a simple proposition: a third party should be able to verify a document’s integrity without trusting the operator’s server. The project’s stated design combines local hashing, Bitcoin-anchored OpenTimestamps proofs, and post-quantum signatures.

The distinctive part is not any single cryptographic primitive. It is the separation of trust roles.

According to the project description, the document is hashed locally on an Android device; the file itself is not uploaded. A receipt records the SHA-256 digest, capture time, signer public key, key fingerprint, signature, and an OpenTimestamps proof. The signed message is a canonical string combining a protocol prefix, the document hash, and the local capture time. A verifier can then check the key fingerprint and ML-DSA-87 signature independently, while ots verify checks the timestamp proof.

That division matters because the two proofs answer different questions. The ML-DSA signature is intended to show who sealed the receipt. OpenTimestamps supplies a Bitcoin-backed claim about when the committed data existed. NIST’s FIPS 204 defines ML-DSA as a digital-signature standard designed for verification and authentication, and describes it as intended to remain secure against adversaries with large-scale quantum computers: FIPS 204.

The project also describes a two-machine operational model. A networked Raspberry Pi reportedly runs the backend and a Bitcoin Core node used to verify timestamp proofs. A separate Raspberry Pi 500 is described as air-gapped and holds the cold ML-DSA-87 signing key. The intended security property is straightforward: compromise of the online service could allow database tampering or false claims, but it should not allow an attacker to manufacture a valid signature from the offline key.

This is a useful distinction for developers building evidence systems. “Post-quantum” does not automatically describe every signature in a product. X-39 explicitly says that its sealed receipts use ML-DSA-87, while live chat messages use Ed25519 and the Android package uses RSA-4096 because of Android signing constraints. The quantum-resistant layer is therefore attached to the sealed result, not retroactively applied to every component.

The Bitcoin side is similarly narrower than a generic blockchain claim. OpenTimestamps is a protocol for creating and verifying timestamp proofs whose Bitcoin attestation can be checked with its client; its documentation says independent verification can use a local Bitcoin Core node, including a pruned node: OpenTimestamps client. In X-39’s model, the ICP canister presents the frontend and verification material, while timestamp verification and cold signing remain outside the canister boundary.

That architecture also clarifies what the system does not prove. A valid hash proves that the presented bytes match the committed digest. A valid signature proves that the corresponding private key signed the canonical message. A Bitcoin timestamp supports an existence-before claim for the commitment. None of those checks, by themselves, establishes that the document’s contents are legally true, that the signer had legal authority, or that the system replaces a public notary or qualified electronic signature.

The project says it is in closed beta, is operated by one person, and is released under AGPL-3.0. Those limitations are important context: the value of the design is currently as a verifiable engineering pattern, not as a substitute for institutional notarization.

Safety note: claims about X-39 Notaría’s deployed canister, live proof bundle, Bitcoin block, and two-machine operational setup are attributed to the project author. This article does not independently reproduce those checks. Readers should treat the published commands, schemas, hashes, and proofs as verification starting points rather than as assurances from the newsroom.

For ICP builders, the broader lesson is practical. Chain Fusion is not only about calling another chain from a canister. It can also mean composing verification surfaces: ICP for distribution and application logic, Bitcoin for external time anchoring, and an offline key for an authority that the online service cannot silently assume.