The .sol Name That Proves We Signed It

The receipt JSON on /security carries a 32-byte ed25519 public key. Anyone can fetch the same key from /api/receipts/public-key and verify a signature locally. That works, but it leaves one question unanswered: who controls that key today?

The answer needs to be something a reader can derive without trusting our database. Database rows can be edited; on-chain records cannot. So we put the signer identity on-chain.

operatoruplift.sol, the on-chain anchor

operatoruplift.sol is a Solana Name Service name we own. SNS is the Solana equivalent of ENS on Ethereum: a smart-contract registry that maps human-readable names to on-chain accounts. The owner of operatoruplift.sol is a Solana account whose public key matches the ed25519 key returned by /api/receipts/public-key. A judge can cross-check the two without our help:

1. Fetch /api/receipts/public-key. Note the base64 32-byte pubkey.

2. Open a Solana explorer (Solscan, solana.fm, or any RPC client) and resolve operatoruplift.sol.

3. Compare the owner pubkey against step 1. If they match, the signer identity is anchored on-chain.

The /security page renders this directly: a small "Signed by operatoruplift.sol" line under the Signed Receipts header, with the link pointing at /api/sns/resolve?name=operatoruplift.sol. A curious user clicks through and sees the on-chain owner field; a technical user opens the explorer and re-derives the chain themselves.

Why this matters more than it sounds

The obvious objection: anyone can claim a .sol name and sign anything. True. The point is not that operatoruplift.sol grants us any moral authority. The point is that if we change the signer key, the name has to update on-chain too, and the update is publicly visible. We cannot quietly rotate the key and continue claiming "operatoruplift.sol signed this" without an explorer showing the rotation.

That gives users a single anchor point: trust the name, watch the on-chain record. If a sophisticated adversary compromises our server and starts signing fake receipts with a different key, the receipts will not check against the name's current owner. The breakage is public.

What does NOT change with SNS

SNS is not part of the signing flow. The receipt's signature is still produced server-side with the ed25519 private key. SNS does not gate execution, does not change the receipt schema, and does not affect the Filecoin mirror. It is a public anchor for the signing identity, nothing more.

It also is not a replacement for an audit. SNS confirms the name-to-key binding at a point in time. An auditor still has to inspect our server code to know that the key in use today is the one bound to the name. The trust chain is: ed25519 signature proves the receipt was signed, SNS proves the signing key is the one we publicly claim, Filecoin proves the bytes are unedited, and the Anchor program on Solana proves the receipts published in order.

Four primitives. Each adds a different kind of public re-derivation. None of them require you to trust the others.

Why not ENS

Most of the codebase is Solana-native and the receipts publish to a Solana Anchor program. Anchoring the signer identity to the same chain keeps the path single-chain: a reader does not need to bridge between two registries. ENS on Ethereum would work; it would just require tracking two chains. Cross-chain SNS / ENS mirroring is a fine roadmap item for the day we publish receipts on Base or Ethereum. Until then, one chain, one identity.

Who reads this and why it matters

If you are a developer building on x402, the SNS anchor pattern is reusable: pick a domain on whichever name service your chain has, publish the signer key as the owner, and cite the name in your receipts. Three lines of explanation in your security policy.

If you are a regulator or an enterprise buyer, the practical answer to "how do we know who signed this" stops being "trust their server" and starts being "look at the explorer." The audit reads the same way whether the buyer cares about ed25519 or not. The chain does the work.