Email Proof of Work

A small Bun app that adds a proof-of-work token to a cold email.

The idea is simple:

• sender spends real compute time to generate a token
• token is tied to the recipient + email content
• recipient can verify the token and signature

This does not prove identity by itself. It is a cost signal that makes bulk spam more expensive.

What this project includes

• Proof generation (CPU)
• Proof verification
• Ed25519 signing of proof payloads
• Web UI for generating + verifying tokens
• JSON API for integrations

Quick start

Requirements

• Bun >= 1.1

Run locally

bun install
bun run start

Open: http://127.0.0.1:8787

Minimal API usage

1) Generate a proof

curl -s http://127.0.0.1:8787/api/generate \
  -H 'content-type: application/json' \
  -d '{
    "recipientEmail":"friend@example.com",
    "subject":"Quick intro",
    "body":"Hey — wanted to reach out.",
    "difficultyBits":20,
    "workers":4
  }'

2) Verify a proof

curl -s http://127.0.0.1:8787/api/verify \
  -H 'content-type: application/json' \
  -d '{
    "recipientEmail":"friend@example.com",
    "subject":"Quick intro",
    "body":"Hey — wanted to reach out.",
    "proofInput":"EMAIL-POW:..."
  }'

Proof format (high level)

• Prefix: EMAIL-POW:
• Signed payload includes:
  • recipient email
  • subject hash
  • body hash
  • timestamp
  • challenge salt
  • PoW difficulty + nonce + hash

Development

bun test
bun run dev

Before open-sourcing: practical checklist

• Add a LICENSE file (MIT/Apache-2.0 are common choices)
• Add a SECURITY.md with a contact method
• Add CONTRIBUTING.md (setup, tests, coding style)
• Confirm no secrets are committed (.env, private keys, API tokens)
• Add CI for bun test
• Pin project metadata (name, version, repository, author)
• Tag a v0.1.0 release with short release notes

Notes

• Default key storage is per-user local config directory.
• Existing legacy POH1: tokens are still accepted by the decoder for compatibility.