FAQ

No. The revealed chains sign a digest that fixes the vault, the nonce, the amount, the destination and the next commitment. The only transaction they authorise is the one you wrote. A stranger who submits it pays your destination and pays the fee.

The signature is 1,088 bytes against a 1,232-byte transaction limit, and verifying it is a few thousand SHA-256 calls against a 1.4 million unit compute limit. One to write the request, five to deliver and verify 34 chains at 8 per transaction, one to finalise.

The request remembers how many chains have landed. Resend from there, with the same signature over the same digest. Never sign a different digest against the same commitment.

No. The request address is derived from the vault's current nonce, so there is one request per vault state. The next one can open once this one finalises, or once it has expired and been cancelled.

No. It is stored as owner_hint so the app can find your vaults. No instruction that moves value checks a signer against anything. If one did, the vault would be exactly as breakable as the wallet it replaced.

The funds are lost. There is no admin, no recovery contact, no timelock and no close_vault.

A multisig protects against a stolen key. It does nothing against a derived one. Five Ed25519 keys fall to Shor's algorithm the same way one does.

Yes. A Solana address is the Ed25519 public key itself, not a hash of it. Any address that appears on chain has published its key.

Grover’s algorithm reduces a preimage search from $2^{256}$ to about $2^{128}$. That is the assumption the vault rests on, and it is the same one NIST’s hash-based signature standards rest on.

Yes. A deposit is a system transfer into the vault's address and needs no permission. Getting value in is meant to be easy; the whole security budget is spent on getting it out.