A vault no ed25519 key can open
The design: a program holds funds at an address that releases them only against a valid WOTS signature over the withdrawal. Each withdrawal spends the vault's key once and rolls the remainder into a fresh vault with a fresh key.
Every sentence above is the future tense, on purpose
No program is deployed. Nothing on this site verifies a signature on chain, no vault exists, and no funds are held anywhere. The paragraph above describes what is specified, and a page that described it in the present tense would be describing something nobody built.
/api/identity/anchor refuses with 501 and names what it is blocked on, rather than returning a success with nothing behind it.
What does exist: the program, compiled
The verifier is written and it compiles to a 158,072-byte Solana object. Before that object is emitted, 8 tests check the Rust against the very vectors this site serves at /vectors/wots.json, including the one that must be refused.
Two implementations of one scheme is the dangerous shape here: the browser signs in TypeScript and the chain would verify in Rust. They are never compared to each other, only to that published file, which a stranger can use too.
- sha256
- 9a6178adb5333762f197476b966d37377231cd5e362365065cd172570e946478
- toolchain
- cargo-build-sbf 4.4.0, platform-tools v1.57, rustc 1.95.0
Compiling it is not deploying it, and this box says which one happened. The build also refused once, on an earlier version: the verifier held the recovered 2,144-byte key on a 4 KB stack frame, and the toolchain said so while still emitting an object and exiting zero. It is now streamed, 32 bytes at a time.
Why it cannot be one transaction
A signature is 2,144 bytes and a full attestation is 2,436. A Solana transaction is capped at 1,232. The signature has to be staged across several writes into a buffer account and verified from there, and any product claiming to fit one into a single transaction is claiming something the chain will not do.
| step | bytes | what it carries |
|---|---|---|
| open | 45 | the root and the leaf this vault answers to |
| write 1 | 880 | public seed + signature, from byte 0 |
| write 2 | 880 | signature, from byte 880 |
| write 3 | 672 | signature + authentication path, from byte 1,760 |
| withdraw | 41 | the amount and the next vault. No account signs it. |
| close | 1 | the buffer’s rent, back to whoever paid it |
2,432 bytes staged into a 2,465-byte buffer account, in writes of at most 880 bytes so a transaction carrying one still fits under 1,232 with room for a second signature. The withdraw instruction has no signer at all: whoever submits it pays the fee and authorises nothing, which is the whole claim this page makes.
The client that builds these six instructions is lib/vault.ts, and probe-vault reads every seed, tag, offset and field order out of the Rust source and fails if the two drift. The withdraw message is checked across both languages: the TypeScript writes vectors to /vectors/withdraw.json and a Rust test recomputes every one of them.
What will be true of it the day it exists
A program will verify the signature on chain
None is deployed today. When one is, whoever holds its upgrade authority can replace it, so until that authority is set to none this page names the key that can.
- program
- none deployed
- upgrade authority
- none, because there is nothing to upgrade
When a program is deployed, that second field will name the key that can replace it, on this page, in this box, until the authority is set to none. A disclosure that lives only in a repository is a disclosure the reader of the claim never sees.
What does work today, with no wallet and no server: checking an attestation.