live · mainnetoc · docs
specs · api · guides
docs / use cases

Use cases

Release / commit signing

Give every tagged release a Stamp envelope committed to the release artifact. Anyone downloading later can verify both authorship (signer's Bitcoin address) and priority (Bitcoin block at time of release).

# Pseudocode for a git-stamp plugin
tar czf release.tar.gz ./dist/
oc-stamp sign --content release.tar.gz --signer bc1qalice... > release.stamp
oc-stamp anchor release.stamp > release.stamp.anchored
git tag v1.2.3 -m "v1.2.3 release"

Distribute release.tar.gz, release.stamp.anchored, and the git tag together. Downstream consumers:

oc-stamp verify --content release.tar.gz --envelope release.stamp.anchored
# ✓ signed by bc1qalice… at 2026-04-24T06:47Z
# ✓ anchored in Bitcoin block 820472 (depth 6+)
# ✓ content hash matches

Better than PGP keysigning because there's no keyserver rot — the Bitcoin address is the canonical identifier, checkable forever.

Long-form publishing

Writer publishes an article at time T. Wants later-provable "I wrote this before X happened" without relying on a centralized blog platform or social-media timestamp.

const article = await fs.readFile('./post.md');
const env = await stamp({
    content: article,
    mime: 'text/markdown',
    signer: { address: writerAddress, signMessage: walletSign },
});
env.ots = await submitToCalendars(env.id);
// Later:
env.ots = await upgradeProof(env.ots, env.id);
await fs.writeFile('./post.stamp', JSON.stringify(env));

Publish the article wherever (RSS, IPFS, Substack, personal blog). The .stamp file is a separate self-contained proof that anyone can check against the content. No reliance on the hosting platform.

An agreement between two parties. Both sign the same content. Both stamps anchor to Bitcoin within the same window. No notary, no centralized service.

// Alice signs
const aliceStamp = await stamp({
    content: agreementBytes,
    mime: 'application/pdf',
    signer: { address: aliceAddr, signMessage: aliceWallet.sign },
});

// Bob signs the same content
const bobStamp = await stamp({
    content: agreementBytes,
    mime: 'application/pdf',
    signer: { address: bobAddr, signMessage: bobWallet.sign },
});

// Both anchor
aliceStamp.ots = await submitToCalendars(aliceStamp.id);
bobStamp.ots = await submitToCalendars(bobStamp.id);

// Store: agreement.pdf + alice.stamp + bob.stamp

A third party verifying both stamps knows:

  • Both addresses signed the same content (content hashes match).
  • Both signings predate the anchor block.
  • Neither party can later deny their signature (it's cryptographic).

If jurisdictional enforcement matters, this is the proof layer — you still need a legal framework that accepts cryptographic evidence.

DAO proposal authorship

DAO proposals are often submitted via a wallet that's not the proposer's actual identity (e.g., a multisig, a delegate wallet). Stamp separates proposer-identity from submitter-identity:

// Proposer signs the proposal content
const proposalStamp = await stamp({
    content: proposalBytes,
    mime: 'text/markdown',
    signer: { address: proposerAddr, signMessage: proposerWallet.sign },
    attest_ref: proposerAttestationId, // for "stake at signing"
});

// Then whoever has submit rights posts the proposal + the stamp on-chain

Voters verifying the proposal see both the on-chain submitter AND the cryptographic authorship chain back to the proposer's Bitcoin address.

Sybil-gated content feeds

Embed an OC Attest reference in every Stamp envelope. Feed aggregators can then filter posts by signer stake:

const post = await stamp({
    content: postBytes,
    mime: 'text/markdown',
    signer: { address: authorAddr, signMessage: authorWallet.sign },
    attest_ref: authorAttestationId,
});

// Aggregator:
for (const incoming of feed) {
    const env = JSON.parse(incoming.content);
    if (!env.attest_ref) continue;
    const check = await fetch(
        `/api/check?id=${env.attest_ref}&min_sats=100000&min_days=30`
    ).then((r) => r.json());
    if (check.ok) showPost(env, postBytes);
}

Low-stake posts filter out at the firehose level; high-stake posts get shown. Combines the authorship + timestamp guarantees of Stamp with the sybil-resistance of Attest.

When Stamp is NOT the right tool

  • You need privacy. Stamp envelopes are public, anchored to a public chain. Use authenticated encryption (OC Lock) instead.
  • You need continuous signing (streaming logs, per-keystroke provenance). Stamp is one-envelope-per-event; wrong granularity.
  • You need proof-of-delivery. Stamp proves "this was signed before X"; it doesn't prove "this was seen by Y." Separate concerns.

See also