# Fast Sign

> Sign any file with a Fast address; the file's SHA-256 fingerprint is settled on-chain, and anyone
> can verify the result. In the website flow, the file's bytes never leave the browser; what is published on-chain is the signed claim — the
> fingerprint, the signer address, and any attestation metadata the signer included (a signer
> name, a file label, listing preferences). Reading
> and verifying need no account, no key, and no API token.

This deployment settles signatures on the `fast:mainnet` network.

## What a Fast Sign signature proves

A verified signature proves three things, and only these:

- The signed original bytes are unchanged — the fingerprint on-chain matches the file (or, for a
  stamped PDF, its signed-original prefix) byte for byte.
- Which Fast address signed, and when the signature settled. A signature may CARRY a signer name,
  but that field is self-declared by the key-holder and is not checked against the Fast ID
  directory — treat it as untrusted. The verify page renders a name as a LINKED Fast ID only when
  it separately resolves the signing address in the directory and the resolved name matches;
  anything else is text attributed to the key-holder, not identity.
- For a stamped PDF: the visible stamp and anything appended AFTER the signed prefix are NOT
  covered by the signature. Verification reports the signed-original length and the unsigned
  appended length separately, and can extract the exact signed original.

## What Fast Sign does not prove

A signature is possession of a key at a point in time, nothing more. It does not prove the signer
read, wrote, or agrees with the file's content; it is not an endorsement, a notarization, or an
identity assertion about a person. A signer-name string INSIDE a signature proves nothing about
name control — it is self-declared. Only a live directory resolution of the signing address to
that same name (which the verify page performs and marks) ties the two, and even then it proves
control of the name's address — see the directory's own llms.txt for what a Fast ID does and does
not assert.

## Public surfaces

- [Home](https://sign.fast.xyz/): what Fast Sign is.
- [Sign](https://sign.fast.xyz/sign): sign a file with a Fast Wallet — a human wallet gesture, not automatable.
- [Verify](https://sign.fast.xyz/verify): drop a file, or paste its SHA-256, to see the on-chain settlements
  recorded for it (the page loads up to the 100 most recent). A stamped PDF also shows its embedded signature receipts.
- [How it works](https://sign.fast.xyz/how-it-works): the signing scheme and what verification checks.
- [Agent guide](https://sign.fast.xyz/AGENTS.md): the HTTP surface for software, including the one read API.

## Not an identity provider

Fast Sign does not issue tokens, sessions, or assertions about users to third parties, and it is
not an OAuth 2.0 or OpenID Connect provider — there is no authorization server here and no
`/.well-known/openid-configuration` to discover. Website signing uses the user's wallet
(the Fast Wallet extension or the app.fast.xyz popup); the public SDK uses caller-supplied signing authority.
This site never holds a key.

## Elsewhere on Fast

- [Fast](https://fast.xyz/llms.txt): the network and its products.
- [`fast` CLI skill](https://skill.fast.xyz/skill.md): lets an agent manage a person's own Fast wallet from the terminal.
- [FAST skill](https://github.com/fastxyz/fast-skill): build Fast payments, bridging and x402 into code (`npx skills add fastxyz/fast-skill`).
- [Fast Shop skill](https://shop.fast.xyz/.well-known/agent-skills/fast-shop/SKILL.md): buy physical products with the Fast Shop MCP server (`npx -y @fastxyz/mcp@latest`).
- [Fast App](https://app.fast.xyz/AGENTS.md): the web wallet.
- [Fast ID](https://id.fast.xyz/llms.txt): names that resolve to Fast addresses.

## Crawling policy

See [robots.txt](https://sign.fast.xyz/robots.txt). It carries a `Content-Signal` line stating the Fast
position on search, agent-time reading, and model training.