Sign messages
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
Sign the message "agent-session-2026-09-09" with agent-1's key, then verify the signature.
Steps
-
Sign. The message is a positional argument, not a flag:
stellar message sign "<MESSAGE>" --sign-with-key <SOURCE>There is no
--messageflag. Passing one fails withunexpected argument '--message' found. -
Verify. The flag name changes from
signtoverify: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:
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.