Skip to content
Lockvane

Whitepaper · v0.2 · September 2026

Discretion for a market that settles in public

Putting equities on a public ledger made every holding legible to strangers and left out the discretion a brokerage statement once gave. This paper sets out a layer that restores some of it, and marks plainly where that layer ends.

DraftNot investment advice

Summary

Stock tokens on Robinhood Chain settle on a ledger anyone can read. Positions, entries, exits and running balances are open to whoever loads a block explorer, for good and without asking the holder. The traditional market these tokens imitate is more private than that: there, only the venue sees the tape.

Lockvane is the private-banking layer for those assets. Holders can receive without exposing their main address through ERC-5564 stealth addresses that are derived wholly in the browser, can invoice and settle privately with a three-scan QR flow that needs no server, and can earn stock tokens for backing the protocol. Nothing in the system holds custody, and no server ever handles a private key.

The privacy promise is kept deliberately small. Lockvane separates who you are from the addresses you receive on. Settlement stays public, amounts stay visible, and nothing is mixed. Each screen in the product says which of these limits applies to it.

1. What is exposed

A wallet with tokenized stock in it is a portfolio on public display. From a single address, anyone can work out cost basis, position size, timing and who you deal with. That has three effects, each of them observable on chain today.

  • Worse execution. A position others can see attracts front-running and fading quotes. The bigger the holder, the poorer the fill.
  • Forced disclosure. Paying someone a single time hands them your full balance history, permanently, and it cannot be withdrawn.
  • Capital that stays away. Funds and treasuries cannot hold an instrument that publishes their book, which limits how much serious money enters.

The familiar response is a pooled mixer, and it does not fit this case. Pooling commingles funds, raises compliance trouble for regulated assets, and still lets a payer learn your address. Lockvane goes the other way: there is no pool, and each payment just lands at a new address.

2. Principles

PrincipleWhat follows from it
Keys stay on the deviceKey material is created, kept and used in the browser only. No account, no email, no recovery service.
Never custodialFunds go from wallet to venue or from wallet to address. No contract under our control holds client balances.
Candid by defaultWhatever is not live carries a planned label in the interface itself, not just in documentation.
Claims you can testEach property described here corresponds to a check in the source that anyone can run.
Present where addresses leakPrivacy must be on hand at the moment an address is pasted, so the extension is treated as a core surface.

3. System layout

The system has three tiers. Only the middle tier involves a server, and only so it can call third-party routers for you.

┌─ Surfaces ────────────────────────────────────────────────┐
│  Web app  (Next.js)          Lockvane extension (MV3)      │
│  keys · QR · claim · sweep   chips · receipts · same keys  │
└──────────────┬────────────────────────────┬───────────────┘
               │  all crypto client-side    │
┌──────────────▼────────────────────────────▼───────────────┐
│  Edge routes: quote · order · tokens · vault · rpc         │
│  holds router keys, never key material, fails closed       │
└──────────────┬─────────────────────────────────────────────┘
               │
┌──────────────▼─────────────────────────────────────────────┐
│  Robinhood Chain 4663 · stock tokens · (planned) announcer, │
│  registry, DividendVault, RevenueRouter, AuditTrail         │
└────────────────────────────────────────────────────────────┘

The RPC relay needs a word of explanation. Some consumer networks intercept the chain’s RPC hostname at DNS, so a working endpoint appears to be down and balance reads fail without warning. Sending browser requests through the application’s own origin removes that problem, and nobody has to reconfigure their network.

4. Cryptography

Stealth addresses are implemented per ERC-5564 on secp256k1. The recipient publishes a meta-address made of two public keys, one for spending and one for viewing, and the sender derives a new address for each payment.

Sender                              Recipient
─────────────────────────────       ─────────────────────────────
r ← random scalar
R = r·G                        →    R arrives with the payment
S = r·K_view                        S = k_view·R          (equal)
h = keccak256(compress(S))          h = keccak256(compress(S))
tag = h[0]                          skip unless tag matches
P = K_spend + h·G                   p = k_spend + h  (mod n)
addr = keccak(P)[12:]               addr == keccak(p·G)[12:]

p can be computed by the recipient alone, so the recipient alone can spend. The view tag is a one-byte filter: a scanner throws away nearly every announcement after one comparison.

Storing keys is optional and stays local. When a passphrase is set, the key set is sealed with AES-256-GCM using a key derived by PBKDF2-SHA256 over 310,000 rounds via WebCrypto. The web app and the extension use the identical sealed format, byte for byte, so a single backup restores into either one.

Round-tripping, the guarantee that an outsider cannot claim a payment, rejection of a wrong passphrase and rejection of tampered data are each asserted by scripts in the source, and they run on every push.

5. Sealed invoices

Until an announcer contract exists, the payer has to pass the ephemeral key to the recipient directly. Lockvane turns that hand-off into the feature itself: a QR code.

ItemContentsFrom → to
Payment requestmeta-address, optional token, amount, memorecipient → payer
One-time addressderived in the payer's browserpayer → chain
Receiptaddress, ephemeral pubkey, view tag, optional tx hashpayer → recipient

A receipt holds precisely the fields of the ERC-5564 announcement event. Once the announcer contract is live, a background scanner takes over from the QR without any format change, and the QR stays available as the offline route for payments that publish nothing on chain.

6. The $LOCKV token

$LOCKV pays for access and lower fees. It cannot buy better routing; every client gets the same route, holder or not. What sets it apart is the form its rewards take: stakers are paid in a basket of stock tokens rather than in additional $LOCKV.

Revenue sourceSettled inBegins
Creator share of $LOCKV trading feesETHAt token launch
Routing fee on private fillsInput assetWhen the router key is live
Relay fee on sponsored sweepsSwept assetRoadmap phase 3

Revenue is converted into the basket on chain and streamed to stakers. The whole model rests on a single on-chain fact: a contract must be able to hold and move the issuer’s stock tokens. That was confirmed on mainnet by simulating transfers of each basket token from actual holders to a contract address. It is true today, and it is checked again before every release, because the tokens are upgradeable proxies that their issuer controls.

Supply is fixed, with no mint function and no admin keys. Distribution is a fair launch on a public bonding curve, with no presale and no team allocation, and the launch transaction hash is made public.

7. Roadmap

PhaseScopeStatus
0Stealth keys, QR private payments, claim and sweep, private swap quotes, extension MVPshipped
1Announcer and registry contracts, background scanner, live quotesnext
2Passkey unlock, viewing-key disclosure, vault contracts and audit scopeplanned
3Sponsored sweeps, native on-chain private route, public APIplanned
4Association-set membership proofs, confidential amounts researchresearch

8. Risks

Set out in full, since a privacy service that overstates its reach does more harm than having none.

  • Issuer control. Stock tokens are upgradeable proxies. The issuer can alter their behaviour at the same address, including transfer restrictions that would undermine the vault design.
  • Metadata exposure. Settlement is public. Analysis of timing and amounts can still connect activity, particularly for unusual sizes.
  • Receipts passed by hand. Until the announcer is deployed, losing a receipt leaves the recipient unable to find funds that are already theirs.
  • Lost keys. By design, nothing can be recovered. A lost spending key means the funds are gone for good.
  • Contracts not yet audited. No contract has been deployed. Treat nothing in the vault section as live until an audit is published.
  • Regulatory exposure. Tokenized equities sit inside a shifting regulatory boundary that differs by jurisdiction and may limit availability.
This paper describes software. It is not a securities offering and contains no investment advice. Any figure not yet produced by a deployed contract is marked planned throughout.

References