Signed Messages for Contract Accounts (draft SEP)

[sayweer]

This is the discussion for a new SEP that does for contract accounts what SEP-53 does for G accounts: a C address signs a human-readable message, and anyone can check that signature against the account's current rules without submitting a transaction. It came out of #1928 and #2027, where @JakeUrban suggested writing it up as its own SEP next to SEP-53, with the SEP-43 change as a separate follow-up.

Why

A contract account doesn't have a single key. Who can act, with what threshold and under which policy is decided in its __check_auth. Checking a message signature against one public key ignores all of that, so a signer that was removed yesterday still produces a "valid" signature today. Right now wallets either throw on signMessage for C addresses or return their own WebAuthn envelope (Stellar-Wallets-Kit #93, #95, #112), and relying parties have no consistent way to verify those.

How it works

• The signature is a SorobanAuthorizationEntry in which the account authorizes one call, verify_message(account, msg), on a small reference verifier contract. msg is a readable map with the domain, a statement, a nonce, issued_at and a few optional fields.
• The verifier calls account.require_auth() and then always fails with a reserved error. Submitting the entry as a transaction does nothing, and the host rolls the nonce back. It still works like a bearer credential though: anyone who holds it can verify it, including another contract on-chain, so msg shouldn't carry anything secret.
• The relying party rebuilds the expected invocation, checks that the verifier instance runs the reference Wasm (by hash) and runs an enforcing simulation. The account's own __check_auth decides, against current ledger state. Nothing is submitted and there's no fee.
• There's no canonical verifier address. Anyone can deploy the reference Wasm, and trust comes from pinning its hash.
• The wallet fills in domain from the requesting origin, the way WebAuthn handles origin, so one site can't get a signature addressed to another.

Where it stands

The whole flow runs on testnet, with transaction links in the results:

• Signatures verify for OpenZeppelin accounts (one signer, and 2-of-3 with a threshold policy) and for a minimal account that isn't OpenZeppelin. The current rules decide: after a signer is removed or the threshold goes up, the old signature comes back invalid.
• A signature submitted on-chain fails and leaves the nonce unused. With a verifier that returns Ok instead, the nonce gets burned, which is why the verifier always fails.
• A fake verifier that skips require_auth gets through without the hash check and is rejected with it.
• Verification takes a median of 0.36 s against the public testnet RPC.

Draft: https://github.com/sayweer/c-sign/blob/main/docs/SPEC.md
Testnet results: https://github.com/sayweer/c-sign/blob/main/docs/EXPERIMENTS.md
Test vectors: https://github.com/sayweer/c-sign/blob/main/vectors/c-sign-v1.json

The reference verifier, a TypeScript library and a passkey sign-in demo are in the same repo (Apache-2.0).

Open questions

1. For wallet teams: is filling in domain from the request origin workable for you across extensions, WalletConnect and mobile? This is the part I'm least sure about.
2. Accounts with delegated signers may need extra supporting entries. I'd like to hear from anyone running those before I settle on a shape.
3. I also looked at a variant bound to the relying party (verify_message_for(account, rp, msg), both sides authorize and nothing reverts, like SEP-45). It drops the always-fail pattern but loses third-party verification. If people prefer it, I can add it.

Feedback welcome. Once things settle I'll open the draft PR.

[Bekirerdem]

Nice write-up. Eunomia (agent treasury on Soroban) would likely be an early user: the treasury owner is a passkey smart account, and today there's no way for them to sign in to a dashboard or prove they control a treasury without sending a transaction. This fills that gap.

One question on OZ accounts with scoped context rules: if an account only has CallContract rules (say, a session rule limited to the USDC contract) and no Default rule, verify_message won't match any rule and the signature fails. Should wallets add a rule for the verifier, or should the spec require signers from a Default-context rule? Worth stating either way, so relying parties can tell "this account can't sign messages" apart from "this signature is invalid".

[sayweer]

Thanks, good question. Short version: I don't think the spec can require Default-rule signers, because nobody on the verifying side can check it. The simulation only tells you whether __check_auth passed, not which rule matched. So it has to be a wallet rule, not a verification rule.

What I'd put in the spec:

• The wallet already knows before signing. It picks the context_rule_ids itself (with OZ 0.8 they're part of the signed digest too), so if no rule covers the verifier it should return a distinct "this account can't sign messages" error instead of a signature. The RP never gets a signature that was going to fail anyway, and invalid keeps meaning invalid.
• Adding a CallContract rule for the verifier works, and since the wallet picks the verifier instance it can point the rule at its own deployment. But whoever is in that rule can sign in as the account. So it should only hold signers you'd let act as the account anywhere. For an agent treasury that means the agent's session key stays out of it, otherwise the RP sees valid for the agent and can't tell the difference.

Right now this is one line under Limitations, which isn't enough. I'll move it into the wallet requirements in the next revision.