splitkey: Three Ways to Own a Vanity Address That the Seller Cannot Touch

Posted on Oct 24, 2026

Every vanity address has the same problem. It is found by brute force, so somebody knows the private key. The question is not “is the seller honest today?”. The question is “what can a copy of that key do tomorrow?”.

I made splitkey.me to answer that question in public, with one rule: every claim must be checkable on-chain, by you, without us.

Answer 1: Stellar, by rotation

A Stellar account is not the same thing as a key. It has a list of signers with weights, and thresholds. So a seller can deliver an account without delivering a key:

  1. Create the account at the vanity address.
  2. Add the buyer’s key as a signer with weight 1.
  3. Set the weight of the found key to 0.

All three steps go in one transaction. After it, a copy of the found key can sign nothing. This is how KeyPlates delivers, and the full transaction is on splitkey.me/stellar.

Answer 2: Solana token mints, by design

A Solana mint address is also a key pair. But the mint key signs only one thing: the createAccount instruction that creates the mint account. After that:

  • the token program owns the account, so the System program cannot move its lamports, create it again, or assign it to another program;
  • the token programs never ask the mint account to sign; the mint authority is a different key, your wallet.

So a copy of the mint key is worthless after creation. There are two caveats. Before creation, the address is not yours yet. And a Token-2022 mint with a MintCloseAuthority can be closed, which frees the address again. The details are on splitkey.me/solana. A devnet demonstration that tries every attack is in progress; the page will show its results.

Note: this is true for mints only. A wallet key keeps full power forever. For wallets, you need answer 3.

Answer 3: split-key, for keys that must stay powerful

This is the cryptographic answer, and the reason for the name. Ed25519 public keys are points on a curve, and you can add points:

you:       pick a secret s_client, publish A_client = s_client·B
searcher:  find an offset i, so that A_client + i·B has the vanity address
searcher:  prove that it knows i (a standard Ed25519 signature), before payment
you:       pay, receive i, compute s_total = s_client + i

The searcher knows i, but not s_client. You know both. Only you can sign. The proof is a normal Ed25519 signature by the scalar i, so any Ed25519 library can verify it. That means no custom verifier code, and custom verifier code is where bugs live.

Some details took more time than the idea:

  • Point validation. The check 8·A ≠ O is not enough. A point s·B + T, with a small torsion point T, passes it but has no usable scalar. The full check is: a canonical encoding, a point on the curve, and 8⁻¹·(8·A) == A.
  • Nonces. If the searcher signs two proofs with the same nonce, the offset leaks. So the nonce is derived from a secret key and the message, and it never repeats.
  • The limit. The final key is a scalar, not a seed. Wallets that import only seeds cannot import it. I put this in the specification, not in the small print.

The protocol is a draft, and it is not implemented yet. I published the specification first, at splitkey.me/protocol, so that people can review it before any code depends on it. In cryptography, “it compiles” is not a security proof. (In other fields too, but there it is only funny.)

A verify tool that does not need us

The verify page runs in your browser and asks public nodes directly:

  • a Stellar account by G… address: its signers, their weights, the thresholds, and a plain verdict;
  • a Stellar federation address, like hello*keyplates.com: the domain’s stellar.toml, its federation server, the account, then the same check;
  • a Solana mint: the owner program, the mint and freeze authorities, the supply, and a warning if a close authority is set.

The site sets no cookies and loads nothing from third parties. It is a trust page, so I did not want a cookie banner on it. The cheapest consent banner is the one that you do not need.

Read and review

If you find a hole in the protocol, please write to me before you write about it. I will thank you in the document, and I will owe you a beer. If you find the hole in point validation, I will owe you two.