> ## Documentation Index
> Fetch the complete documentation index at: https://developers.stellar.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Sign messages

> Sign and verify a message offline with `stellar message sign` and `stellar message verify`, SEP-53.

Prove control of a key by signing a piece of text, and let someone else verify it. `stellar message sign` and `verify` implement SEP-53 and run fully offline, with no funded account or network flag.

## Ask your agent

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Sign the message "agent-session-2026-09-09" with agent-1's key, then verify the signature.
```

## Steps

1. Sign. The message is a positional argument, not a flag:

   ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
   stellar message sign "<MESSAGE>" --sign-with-key <SOURCE>
   ```

   There is no `--message` flag. Passing one fails with `unexpected argument '--message' found`.

2. Verify. The flag name changes from `sign` to `verify`:

   ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
   stellar message verify "<MESSAGE>" --public-key <PUBLIC_KEY> --signature <SIGNATURE>
   ```

## Flag names are not symmetric

`sign` takes `--sign-with-key`, which accepts an identity name, a secret key, or a seed phrase. `verify` takes `--public-key`, which accepts an identity name or a `G...` address. Passing a secret key to `verify`, or a public key to `sign`, is a straightforward wrong guess. Read the flag name on each side before scripting both into one agent workflow.

## Exit codes make this scriptable

`verify` exits `0` on a valid signature and `1` on an invalid one. Signatures are base64. This makes `stellar message verify` usable directly in a shell conditional, with no output parsing required:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
if stellar message verify "<MESSAGE>" --public-key <PUBLIC_KEY> --signature <SIGNATURE> > /dev/null 2>&1; then
  echo valid
fi
```

## What this proves

SEP-53 proves control of a single key. It does not prove control of an account. An account under multisig, or one where the signing key has since been rotated out of its signer list, can still produce a valid SEP-53 signature from that key, one that no longer means anything about the account itself. Treat message signing as key-level proof of identity, not account-level authorization.

## Common pitfalls

`--base64` tells both commands to treat the message as base64-encoded binary rather than plain text. Leave it off for a plain string message, or `sign` and `verify` hash different bytes and every signature looks invalid.

## Related pages

* [Delegate spending](https://developers.stellar.org/docs/tools/cli/agent-cli/guides/delegate-spending.md)
* [Authority model](https://developers.stellar.org/docs/tools/cli/agent-cli/reference/authority-model.md)
* [Quickstart](https://developers.stellar.org/docs/tools/cli/agent-cli/quickstart.md)