Stamp a whole project — per-file proofs plus a project anchor

A canonical JSON manifest committing to every file's SHA-256 plus the project name, description, and timestamp. Schema id bastamp.project/v1:

{
  "schema": "bastamp.project/v1",
  "name": "Case 2025-0042",
  "description": "Exhibits A through G",
  "createdAt": "2026-05-13T12:00:00.000Z",
  "files": [
    { "name": "exhibit-a.pdf", "sha256": "0x...", "size": 184326 },
    { "name": "exhibit-b.pdf", "sha256": "0x...", "size": 92044 },
    { "name": "exhibit-c.pdf", "sha256": "0x...", "size": 308112 }
  ]
}

The manifest's canonical SHA-256 is what we anchor. The files themselves never leave your machine — only their hashes go into the manifest, only the manifest's hash goes to bastamp.com.

Each file in the project is anchored individually (own on-chain stamp, own /verify/<file-hash>URL, own certificate) — exactly the same pricing as the bulk upload flow. On top of that, the project manifest is anchored as one extra stamp so the project gets its own URL that lists everything. Total: N + 1 credits for N files.

All N + 1 stamps go in the same on-chain batch (one transaction, one Polygon block) — the project is atomic. Max project size is 99 files in v1; larger projects need chunking and aren't supported yet.

import { BAStamp } from "@bastamp/sdk";
import { readFile } from "node:fs/promises";

const client = new BAStamp({ apiKey: process.env.BASTAMP_API_KEY! });
const r = await client.projects.stamp({
  name: "Case 2025-0042",
  description: "Exhibits A through G",
  files: [
    { name: "exhibit-a.pdf", content: await readFile("exhibit-a.pdf") },
    { name: "exhibit-b.pdf", content: await readFile("exhibit-b.pdf") },
    { name: "exhibit-c.pdf", content: await readFile("exhibit-c.pdf") },
  ],
});

// Save the manifest with the project files:
await fs.writeFile("project.manifest.json", JSON.stringify(r.manifest, null, 2));

If the files are sensitive and you don't want them in memory, pre- hash and pass sha256 per file instead of content. The bytes never enter the SDK.

1. The party receiving the project also receives project.manifest.json (the manifest the SDK returned).
2. They drop the manifest on bastamp.com/verify/<hash>. The page canonicalizes and recomputes SHA-256 — must match the on-chain anchor. The full file list is rendered inline.
3. To verify any individual file: drop it on the same page below the file list. The page hashes the file locally and tells the verifier whether its SHA-256 appears in the manifest under any name.
4. For fully trustless verification (no bastamp.com involved): the open-source stamp-verify CLI queries the Polygon Stamper contract directly.

• Legal — exhibits and case bundles. Anchor everything you intend to file at the moment of submission; opposing counsel cannot dispute the timestamp of any single exhibit without challenging the manifest's on-chain anchor.
• IP — design submissions. A multi-file design package (sketches, source files, exports) stays cryptographically linked even when individual files travel separately.
• Software — releases. Stamp the source tarball, the binary, the SBOM, and the changelog as one event. Any consumer can later prove that the artifact they downloaded corresponds exactly to what was released.
• Archives — long-term preservation. Periodic project stamps create an audit trail of an archive's state at specific points in time without ever uploading the contents.

The manifest records the names and hashes you put in it at the moment of stamping. It does not establish authorship, originality, or that the files were created by the entity stamping them. A project stamp is best combined with digital signatures, a custody log, and standard metadata when those questions matter for the evidentiary chain.

For projects beyond 99 files the per-batch limit kicks in and the manifest grows unwieldy. The schema is versioned (v1) so a future Merkle-tree variant can extend it without breaking existing verifiers.