Docs Get started

Prove you sent it.
Prove they got it.

Send a file so that both sides can prove it happened. Encrypted on your own machine, stored only as long as it is needed, and the delivery receipt is written once — editable by nobody, including us.

Read the docs
What people send
  • ◳
    Design filesHand off artwork and prove the client received it.
  • ✎
    Copy and draftsDeliver a manuscript with a timestamp nobody can dispute.
  • ⌗
    Architecture and plansIssue drawings to a contractor, on the record.
  • ‹›
    Source codeTransfer a build to a client who paid for it.
  • ◈
    Anything privateContracts, scans, keys — it is opaque to everyone but the recipient.
How it works

Two sides, one record.

Neither side needs a wallet, a token, or to know what Swarm is. They sign in, and the rest is arithmetic.

The sender
  1. Sign inGoogle gives you an account and a wallet whose key only you hold.
  2. Take a nameYou become alice.pinesign.eth. Your encryption key is published in its records.
  3. Pick a fileThe extension encrypts it on your machine, addressed to the recipient's key.
  4. Send the linkOnly ciphertext leaves your computer. You have already signed for what you sent.
The recipient
  1. Open the linkIt names you specifically. Anyone else who opens it sees nothing but a refusal.
  2. Sign inSame two steps: an account, and a name that publishes your key.
  3. AcceptThe file decrypts on your machine. Accepting and decrypting are one act.
  4. The receiptProof you received it is written once. Neither of you can take it back.

If the recipient never accepts, the file and its link expire together. Nothing to delete, nothing left behind.

Under the hood

Why it holds up.

No key is ever sent

The sender's private key and the recipient's public key produce a shared secret; the recipient computes the identical one from the other direction. Nothing secret crosses the wire.

The gateway is blind

It pays for storage and sees only ciphertext. It cannot read a file, and could not hand one over if compelled.

Proof of decryption

The receipt requires a value only the decrypted file yields. Claiming without opening the file is not possible.

Expiry is passive

The stored blob and the name pointing at it lapse on the same clock. Deletion is not a promise anyone has to keep.

Names do real work

A name is how the sender discovers where to encrypt. No name, no published key, nothing to send to.

Write once

The receipt contract has no owner and no upgrade path. It records that a transfer happened, once, and then cannot say otherwise.

The full mechanism, the threat model, and how to run your own server.

Read the docs