Guide · Paper

How $LAMPORT protects itself.

Start with the plain-English guide. When you want the proofs, switch to the paper.

1.What $LAMPORT is

$LAMPORT is the first Solana token that protects itself. Every transfer runs through a transfer hook that checks for a second, quantum-proof key, so even if someone steals your wallet key, through a hack, a leaked seed phrase or a future quantum computer, they still can’t move your bag. You hold it like a vault and trade it like any other memecoin.

The short version: $LAMPORT is a Solana token with a bodyguard built in, a transfer hook that blocks any transfer without your quantum-proof second key, so a stolen wallet key can’t touch your bag.

2.One key opens everything

Today a Solana wallet has one key. Whoever has it can move everything, however they got it: a phished seed phrase, a malicious approval, a screenshot in the cloud, an AI-found math shortcut, or one day a quantum computer. The chain checks the signature, not the person.

3.A rule the token carries everywhere

$LAMPORT is a Token-2022 token with a transfer hook. Every time anyone moves it (a send, a sell, a swap, a drainer’s sweep), Solana automatically asks the Lamport hook “is this allowed?”. If the hook says no, the whole transaction fails. Nothing moves.

4.Arming adds a second lock

When you arm your bag, your browser creates a second key built only from hashes (quantum computers can’t fake it) and registers its public part with the hook. From then on your $LAMPORT needs two things to move: your wallet signature and proof from the second key.

Lock 1 · wallet signature (ed25519)

Lock 2 · second-key proof (hashes)

→

The hook checks both

→

both present → transfer passes

signature only → blocked

Fig. 1 — Two locks. The wallet key alone no longer opens an armed bag.

5.Daily use

You click Send or Swap as usual. The app attaches the second-key proof for you in two quick steps: it announces the transfer, waits about two seconds, then reveals the proof and moves the tokens. One button, both steps.

6.If your wallet key is stolen

The thief can sign, but can’t produce the proof. The hook sees a wallet signature without second-key proof and rejects the transfer. Because the second key is kept separate from your seed phrase, this already protects you from ordinary seed-phrase leaks and drainers today, not just from future quantum computers.

7.The Quick Key: one-time passwords that check themselves

Your everyday second key is a stack of one-time passwords. A secret is hashed thousands of times and only the final result is registered. Each transfer reveals the link just before it, and the hook hashes that link once to check it matches. Hashes are one-way, so nobody can work backwards from what is public to what comes next.

The two steps (announce, then reveal) stop anyone from copying a password mid-flight: by the time a link is visible, it has already been used. Try it yourself in the Quick Key toy.

8.The Master Key

The Master Key is a heavier quantum-proof signature (WOTS/XMSS) with 1,024 one-time uses, kept for rare actions: turning protection off, resetting the Quick Key when it runs low, and cancelling a recovery. You will rarely touch it, so keep its backup somewhere safe and separate.

9.If you lose your second key

You can disarm with only your wallet, but it takes 7 days, and your second key can cancel it at any time during those 7 days. That means a thief with only your wallet key can start the clock, and you can stop it.

Day 0 · request with wallet keyDays 0–7 · cancel with Quick or Master KeyDay 7 · protection off

Fig. 2 — The 7-day recovery. Either second key can cancel until the timer runs out.

10.Trading still works

Liquidity pools are program-owned accounts with no private key, so the hook lets them through. That means buying works from any app. Holders who haven’t armed trade like any normal token, and armed holders sell through the $LAMPORT app, which adds the proof to the swap automatically.

11.The honest limits

Unarmed holders are as exposed as with any token. Protection is opt-in.
Armed transfers take one extra quick step (about two seconds).
Someone with a leaked wallet key can still burn armed tokens (burns don’t trigger hooks), though they can never take them.
The protection covers $LAMPORT only. SOL and other tokens in the same wallet are not protected (yet).
If your wallet key is stolen and you have lost both second-key backups, you can’t stop a recovery request. Keep the backups.

12.What’s next

The Lamport Hook standard lets any new token plug in the same hook, with one arming setup protecting every Lamport-hooked token you hold. Armored wrappers turn SOL, USDC or any SPL token into a hook-protected qSOL or qUSDC, 1:1. And $LAMPORT becomes the platform token: fees from hooked launches and wrappers feed buybacks.

$LAMPORT is not affiliated with or endorsed by Leslie Lamport.

Download PDF Print view

Preprint · v0.1 (pre-audit) · October 2026

LAMPORT: A Self-Protecting Token on Solana

The LAMPORT contributors · lamport.computer

Abstract

A Solana account is controlled by a single ed25519 key: whoever holds it, whether through phishing, malware, a leaked seed phrase or a future cryptanalytic break, can move everything in it. We present $LAMPORT, a Token-2022 token whose transfer hook refuses any transfer from an armed account unless the same transaction carries proof from a second, hash-based key. The everyday proof is a link of a Lamport hash chain, revealed through a commit–reveal step that defeats front-running; rare administrative actions use a stateful hash-based signature (WOTS/XMSS). Holders opt in, pools and unarmed holders are unaffected, and a seven-day recovery that the second key can veto handles lost keys. We describe the protocol, its accounts and instructions, a security argument, and its honest limits.

1Introduction

Every signature scheme in production use on Solana today rests on the hardness of the elliptic-curve discrete logarithm problem. That assumption is challenged from three directions at once: everyday key theft (phished seed phrases, malicious approvals, wallet drainers), the possibility of a new classical algorithm, and Shor’s algorithm on a large quantum computer [5]. In every case the outcome is the same: an adversary holds a valid signing key and the chain cannot tell them from the owner.

Hash functions offer a different footing. In 1979 Lamport showed how to build digital signatures from any one-way function [1]; in 1981 he proposed authenticating with a chain of hashed passwords, each used once [7]. Both need nothing but preimage resistance, which quantum computers weaken only quadratically [6]. Their limitation is statefulness: each key may be used once, or a fixed number of times.

Token-2022’s TransferHook extension lets a mint name a program that Solana invokes on every transfer of the token, including transfers initiated by delegates and DEX programs, and whose failure aborts the whole transaction [9]. We use that hook to enforce a second factor at the token level: once a holder arms their token account, the hook rejects any outgoing transfer that is not accompanied, in the same transaction, by a fresh link of the holder’s hash chain. A stolen wallet key, of any provenance, is no longer sufficient.

Our contributions are:

a commit–reveal protocol that turns a Lamport hash chain into a per-transfer, front-running-resistant proof that the hook can check with one hash (§4);
a stateful XMSS-style Master Key for rare actions, staged across transactions to fit Solana’s limits (§5);
a time-locked recovery that the second key can veto (§6); and
a security argument and an explicit list of limitations (§7–§8).

2Threat model

Adversary. The adversary $\mathcal{A}$ knows the owner’s ed25519 secret key and can therefore sign any transaction the owner could. $\mathcal{A}$ sees all on-chain state and all transactions as they are broadcast, and can submit its own transactions with arbitrary priority fees. $\mathcal{A}$ does not know the Quick Key secret $x_0$ or the Master Key seed, which are generated independently of the wallet seed and stored apart from it.

Assumptions. $H$ is SHA-256, modelled as preimage- and second-preimage-resistant; against quantum adversaries we assume the generic Grover bound, $2^{128}$ work for a preimage. Solana’s consensus and the Token-2022 program behave as specified. The owner’s reveal transaction is included within $\Delta = 4$ slots of being broadcast (see §8 for what happens if it is censored for longer).

Goals. (G1) Unstealability: $\mathcal{A}$ cannot reduce the balance of an armed token account by any transfer. (G2) Liveness: the owner can always transfer. (G3) Recoverability: an owner who loses the second key can disarm with the wallet key alone, after a delay during which the second key can veto.

Out of scope. Burns (which do not invoke transfer hooks), assets other than $LAMPORT, compromise of the device while it holds both keys in the clear, and implementation bugs (addressed by audit and immutability).

3Design

$LAMPORT is a Token-2022 mint with the TransferHook (program lamport_hook), MetadataPointer and TokenMetadata extensions, six decimals and a fixed supply. After launch, the mint authority, freeze authority and transfer-hook authority are set to none, there is no permanent delegate and no transfer fee, and both programs are made immutable after audit, so no single key, including the authors’, can change the rules.

Holder’s app
wallet key + Quick Key

→

lamport_auth
commit · reveal · master

→

Armor · Commit
Session · SigBuffer

Token-2022
transfer_checked

→

lamport_hook
Execute

←

reads Armor, Session
+ Instructions sysvar

Fig. 1 — Architecture. lamport_auth holds per-account state and verifies proofs; lamport_hook is called by Token-2022 on every transfer and reads that state.

Table 1 — Program-derived accounts of lamport_auth.

Account	Seeds	Fields
`Armor`	`["armor", token_account]`	owner, token_account, quick_anchor (32 B), quick_links_remaining, master_root (32 B), master_next_leaf, recovery_delay_slots, recovery_unlock_slot?
`Commit`	`["commit", armor, commitment]`	slot
`Session`	`["session", token_account]`	slot, remaining, link
`SigBuffer`	`["sig", armor, digest, payer]`	staged Master Key signature bytes

The hook’s ExtraAccountMetaList resolves, for every transfer, the source account’s Armor PDA, its Session PDA (writable) and the Instructions sysvar. Its decision procedure is:

Algorithm 1 · lamport_hook::Execute(source, amount)

if owner(source) is off-curve (a PDA: pool, vault) → allow
if Armor(source) does not exist → allow (unarmed)
require Session.slot = current slot
require Session.remaining ≥ amount
require an earlier instruction in this transaction is lamport_auth::reveal for source
Session.remaining ← Session.remaining − amount; allow
otherwise fail with LamportArmed

Delegated transfers carry no special privilege: the hook judges the source account, so a delegate (or a drainer holding an approval) faces the same requirement as the owner. Arming requires the token account to carry the ImmutableOwner extension, so a stolen key cannot reassign the account’s owner to escape the Armor.

4The Quick Key protocol

4.1Setup

The client draws a 32-byte secret from the system CSPRNG, independent of the wallet seed, and computes the chain

\ell_0 = x_0 \xleftarrow{\$} \{0,1\}^{256}, \qquad \ell_i = H(\ell_{i-1}), \qquad a = \ell_n,\quad n = 10\,000

(1)

arm(quick_anchor = a, quick_len = n, master_root, recovery_delay), signed by the owner, stores $a$ in the Armor account. Links are recomputed on demand from $x_0$ , which is kept encrypted under a passphrase (scrypt or Argon2id, then AES-256-GCM) in the browser and in a downloadable backup.

4.2Announce, then reveal

To transfer $v$ units with the next link $\ell = \ell_{k-1}$ (where the current anchor is $a = \ell_k$ ), the client first posts a commitment binding the link to the exact transfer:

c = H\big(\texttt{"lamport/commit/v1"} \,\|\, \ell \,\|\, v \,\|\, \nu \,\|\, s_{\mathrm{exp}} \,\|\, \mathit{account}\big)

(2)

where $\nu$ is a random nonce and $s_{\mathrm{exp}}$ an expiry slot. commit(c) may be paid by anyone and records the current slot. Once the commitment is at least $\Delta = 4$ slots old, a single transaction carries reveal(ℓ, v, nonce, s_exp) followed by the Token-2022 transfer. reveal checks

\exists\, \mathit{Commit}(c):\; s_{\mathrm{now}} - s_c \ge \Delta, \qquad s_{\mathrm{now}} \le s_{\mathrm{exp}}, \qquad H(\ell) = a

(3)

and then updates state atomically:

a \leftarrow \ell, \qquad \mathit{links} \leftarrow \mathit{links} - 1, \qquad \mathit{Session} \leftarrow (s_{\mathrm{now}}, v, \ell), \qquad \text{close } \mathit{Commit}(c)

(4)

The hook (Algorithm 1) then accepts the transfer only in the same slot, only up to $v$ , and only if the reveal precedes it in the same transaction. The commit’s rent is refunded when it is closed.

tx 1 · slot s

lamport_auth::commit(c) → Commit(c).slot = s

wait

≥ 4 slots

tx 2 · slot s′

lamport_auth::reveal(ℓ, v, nonce, s_exp) → anchor ← ℓ, Session(s′, v)
token_2022::transfer_checked(v) → lamport_hook::Execute ✓

Fig. 2 — The two-step armed transfer. The app runs both steps behind one button; the wait is about 1.6 s.

Why the announcement? A revealed link is public the moment the reveal transaction is broadcast. Without the commitment, an adversary holding the wallet key could copy $\ell$ into its own transaction and race the owner. With it, any commitment the adversary creates for $\ell$ is necessarily younger than $\Delta$ slots when the owner’s reveal lands, and the owner’s reveal advances the anchor past $\ell$ in the same transaction, so $\ell$ is never accepted twice (Lemma 1).

5The Master Key

Rare actions (disarming, rotating the Quick Key, cancelling recovery, changing the recovery delay) require a signature from a stateful hash-based scheme in the XMSS family [3]: Winternitz one-time signatures (WOTS) with $w = 16$ over SHA-256 with tweakable-hash domain separation, aggregated by a Merkle tree of height $h = 10$ , giving $2^{10} = 1\,024$ one-time keys under one public root $R$ . The signed digest binds the program, the account, the action and its parameters:

d = H\big(\texttt{"lamport/master/v1"} \,\|\, \mathit{program\_id} \,\|\, \mathit{armor} \,\|\, \mathit{action} \,\|\, \mathit{params} \,\|\, i\big)

(5)

With $n = 32$ bytes and $w = 16$ , a WOTS signature has $\ell_1 + \ell_2 = 64 + 3 = 67$ chain values (2,144 bytes); with the height-10 authentication path it exceeds one transaction, so it is staged into a SigBuffer with stage_master_sig(offset, chunk) and verified by master_action(action, leaf_index, auth_path), which recomputes the WOTS public key, the leaf and the path to $R$ . The program enforces a strictly increasing leaf index,

i \ge \mathit{master\_next\_leaf}, \qquad \mathit{master\_next\_leaf} \leftarrow i + 1,

(6)

so a one-time key is never accepted twice, even if the client’s own usage ledger is lost.

6Recovery

An owner who loses the second key calls request_recovery() with the wallet key alone, setting $\mathit{unlock} = s_{\mathrm{now}} + \delta$ with default $\delta = 1\,512\,000$ slots (about seven days). Until then, either second key can cancel: cancel_recovery_quick with a valid Quick Key reveal, or the CancelRecovery Master action. After the unlock slot, finalize_recovery() disarms the account.

day 0 · request_recovery (wallet key)any time · cancel (Quick or Master Key)day 7 · finalize → disarmed

Fig. 3 — Recovery timeline. A thief with only the wallet key can start the clock; the owner stops it with either second key.

7Security analysis

Theorem 1 (Unstealable). Under the threat model of §2, no transfer that reduces the balance of an armed token account passes the hook unless the transaction contains a preimage of that account’s current anchor.

Proof sketch. Algorithm 1 allows a transfer from an armed account only if a reveal for that account succeeded earlier in the same transaction, which by (3) requires a preimage of the current anchor under $H$ . By preimage resistance, $\mathcal{A}$ cannot compute one from $a$ ; by Lemma 1 it cannot use one the owner reveals; by Lemma 2 it cannot reuse an old one. ∎

Lemma 1 (Front-running). A link $\ell$ revealed by the owner cannot be used by $\mathcal{A}$ : $\mathcal{A}$ learns $\ell$ only when the owner’s reveal is broadcast, so any commitment it makes to $\ell$ is younger than $\Delta$ when the owner’s reveal (included within $\Delta$ slots, by assumption) advances the anchor to $\ell$ , after which $H(\ell) \neq a$ .

Lemma 2 (No replay). A session authorises at most $v$ units, in one slot, in the transaction that created it; the anchor advances on every reveal, so a link is accepted at most once.

Lemma 3 (No back doors). Delegated transfers, swaps and drains are judged by the source account (Algorithm 1); owner reassignment is impossible (ImmutableOwner); Master Key leaves are single-use by (6).

Quantum adversaries. A quantum computer that breaks ed25519 yields exactly the adversary of §2: a party holding the wallet key. Theorem 1 then applies unchanged. The remaining primitive, SHA-256, retains roughly 128-bit preimage security against Grover’s algorithm [6].

Composability. Pools and program vaults are off-curve and pass step 1 of Algorithm 1, so buying $LAMPORT, providing liquidity and receiving tokens work everywhere. Selling from an armed account requires the venue integration (or the $LAMPORT app) to place the reveal before the swap instructions, which aggregator “swap-instructions” APIs permit.¹

8Limitations

Unarmed holders are as exposed as with any token. Protection is opt-in, by design.
Burns. Token-2022 burns do not invoke transfer hooks, so an adversary with the wallet key can burn armed tokens. It can never take them; a burn only reduces supply.
One extra step. An armed transfer is two transactions about 1.6 s apart, with one extra fee (the commit’s rent is refunded).
Scope. Only $LAMPORT is protected. SOL and other tokens in the same wallet are not (see §9).
Censorship race. If the owner’s reveal is broadcast but withheld from inclusion for at least $\Delta$ slots, an adversary who also holds the wallet key could commit to the exposed link, wait, and race the owner. Clients mitigate by submitting through several independent paths and retrying immediately; binding commits to a key derived from $x_0$ would remove the race and is planned.
Both factors lost. If the wallet key is stolen and both second keys are lost, the adversary can request recovery and the owner cannot veto it. Recovery also assumes the owner notices a request within the delay; the app surfaces pending requests prominently.
Endpoint compromise. Malware on a device that holds the wallet key and the decrypted Quick Key at the same moment defeats the separation. Hardware-held second keys are future work.
Implementation risk. Both programs will be audited before mainnet and then made immutable; until then this document describes intended behaviour.

9Future work

The Lamport Hook standard: any new mint can name the same hook at launch, and a single arming setup can protect every Lamport-hooked token a holder owns. Armored wrappers: deposit SOL, USDC or any SPL token and receive a 1:1 hook-protected wrapper (qSOL, qUSDC), with the underlying held by a program account that has no private key. Platform economics: fees from hooked launches and wrappers fund $LAMPORT buybacks.

References

[1]L. Lamport. Constructing digital signatures from a one way function. Technical Report CSL-98, SRI International, October 1979.
[2]R. C. Merkle. A certified digital signature. In Advances in Cryptology: CRYPTO ’89, LNCS 435, Springer, 1990.
[3]A. Hülsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. XMSS: eXtended Merkle Signature Scheme. RFC 8391, IRTF, 2018.
[4]NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA). 2024.
[5]P. W. Shor. Algorithms for quantum computation: discrete logarithms and factoring. In Proc. 35th FOCS, IEEE, 1994.
[6]L. K. Grover. A fast quantum mechanical algorithm for database search. In Proc. 28th STOC, ACM, 1996.
[7]L. Lamport. Password authentication with insecure communication. Communications of the ACM 24(11), 1981.
[8]N. Haller. The S/KEY One-Time Password System. RFC 1760, IETF, 1995.
[9]Solana Program Library. Token-2022 and the Transfer Hook Interface. Solana Labs / Anza documentation.
[10]D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, B.-Y. Yang. High-speed high-security signatures. Journal of Cryptographic Engineering 2(2), 2012.

1.Liquidity venues must support transfer-hook mints; at the time of writing, Orca Whirlpools does so through token badges, and a minimal constant-product pool with full hook support is planned as a fallback. ↩

$LAMPORT is not affiliated with or endorsed by Leslie Lamport.