Whitepaper
The full protocol design, version 1.0.
Document status: version 1.0. It covers the full design, including modules that come later. What exists today is on the Project status page, and every address, once published, is on Network and contracts. The rest of these docs explain the same design in plain words.
Lethe is a privacy-focused asset management protocol on Elysium, named for the river of forgetting that flows past the Elysian Fields. Supported tokens are shielded into a pool, organised into private vaults, transferred confidentially between shielded accounts, and withdrawn to any address, with the option to share a single payment record instead of a whole history.
1. Overview
Lethe moves supported tokens on Elysium into a shielded environment where balances, internal transfers and treasury activity are no longer written in the open. Users shield an existing asset such as HYPE or a supported stablecoin, organise it into vaults, pay other shielded accounts, and withdraw to any address. No dedicated privacy coin is required: the protocol works on the assets people already hold on Elysium.
The design rests on four parts: shielded accounting (ownership as cryptographic commitments, spending by zero-knowledge proof), vaults (private organisation of balances), verifiable authorisation (every action bound to its asset, value, destination and deployment) and deliberate disclosure (a receipt or a scoped viewing key, chosen by the owner). Deposits and withdrawals remain public on Elysium. Lethe reduces linkage inside the shielded system; it does not promise that every action disappears.
This document describes protocol version 1.0 as designed for Elysium (mainnet chain ID 99901, testnet chain ID 99801). Contract addresses, circuit versions and fee parameters are published per deployment in the documentation, not in this paper.
2. The problem
A public ledger shows more than the transaction in front of you. Anyone can read a wallet’s full holdings, its counterparties, the timing and size of its trades, and from those the patterns of a person or a team. On a young chain with few participants, like Elysium today, the picture is sharper still: a handful of large holders, their wallets labelled by block explorers and trackers within hours.
Spreading funds across wallets does not fix this. The funding transaction links the new wallet to the old one, repeated behaviour (same amounts, same hours, same counterparties) re-links them, and every withdrawal to an exchange leaves a trail. Teams face the same exposure for payroll, contributor rewards and treasury operations: every payment is a public announcement of who was paid and how much.
The aim is confidentiality for supported activity together with verifiable accounting: the chain can check that no value was created or taken, without learning who holds what or who paid whom.
3. Protocol scope
The core protocol covers shielding, confidential balances, vaults, private transfers, payment requests, withdrawals and selective sharing. Two further modules, swaps and shared treasuries, ship separately: each has its own contracts, its own privacy description and its own security review before it is enabled on a deployment.
Every deployment publishes its host chain, supported assets, contract versions and fee rules. The Elysium deployment:
| Item | Value |
|---|---|
| Host chain | Elysium, chain ID 99901 (testnet 99801) |
| Native asset | HYPE (shielded through its wrapped form) |
| Supported assets at launch | Published in the documentation with each adapter; stablecoins added as issuers deploy on Elysium |
| Pool, verifier and adapter addresses | Published per release with source and circuit versions |
| Administrator | A multisig with one power: turning deposits of a token on or off |
Privacy applies within supported operations. It does not extend across bridges, into external DeFi protocols, or to anything that happens before a deposit or after a withdrawal.
4. Shielded asset accounting
A deposit locks tokens in the pool contract and creates a commitment: a hash that binds an asset, an amount, an owner key and a random secret. The commitment is appended to a Merkle tree on chain; the matching note (the amount and secret in clear) is encrypted to the owner and stored where only the owner’s keys can read it. Nothing on chain says which commitment belongs to whom.
Spending a note means proving, in zero knowledge, that the spender knows a note in the tree, holds its spending authority, and that value is conserved. The proof reveals a nullifier, a one-way tag derived from the note, which the contract records so the same note can never be spent twice. The proof is bound to the deployment, the asset, the output commitments, the fee and an expiry, so it cannot be replayed elsewhere or altered in flight.
The conservation rule the verifier enforces on every action:
Input notes + public deposits = output notes + public withdrawals + fees
The proof system, circuits and verifier contracts are published with each implementation and pinned by version in the documentation, so that anyone can rebuild the verifier and compare bytecode.
5. User control and keys
Spending authority never leaves the user. Connecting a wallet does not by itself create a privacy account: the client creates a separate key set on the user’s device from fresh randomness, shown once as a 24-word recovery phrase, and that key set is what owns notes. Recovery never depends on a wallet reproducing the same signature. Three kinds of material serve three purposes:
| Material | Lets the holder | Never lets the holder |
|---|---|---|
| Spending key | Move shielded funds, create proofs | — |
| Viewing key | Read balances and history (scoped per vault or per period where supported) | Move funds |
| Recovery phrase | Recreate the spending and viewing keys on a new device | — |
Notes and proof witnesses are processed on the user’s device. If a deployment offers remote proving or holds viewing keys on a server for convenience, that must be disclosed in the documentation and chosen by the user, never a silent default. Losing the recovery phrase can make shielded funds permanently inaccessible; no operator can recover them.
6. Private vaults
A vault is a compartment inside a shielded account: trading, long-term holdings, community operations, contributor rewards, whatever the owner decides. Each vault keeps its own local records and, where the deployment supports it, an authorisation policy. Vault names and groupings live on the user’s device and are never written to chain.
A vault is not a separate anonymity set, not a legal entity and not extra cryptography. Moving a whole note to another vault is a bookkeeping change on the device and costs nothing; moving part of a note needs a private transfer to yourself, because the note has to be split. What protects the funds is the pool and the proofs; what the vault adds is order.
7. Transaction lifecycle
Every shielded asset goes through the same four steps. Two are public, two are private.
Shield (public). The user approves a deposit of a supported token (with a separate allowance where the token needs one) and the client shows submitted, confirming, credited or failed. The deposit is an ordinary Elysium transaction: the depositor, the asset and the amount are visible to anyone.
Transfer (private). The client selects input notes, builds a recipient note and a change note, generates the proof on the device and submits it, directly or through a relayer. The chain sees that a valid action happened and which nullifiers were consumed; it does not see the sender, the recipient or the amount. A transfer addressed to an ordinary public address is not a transfer: it is a withdrawal.
Receive (private). A payment request carries an asset, an amount, a shielded destination and an optional expiry, and can be shared as a link or a code. A request is an invitation to pay, not proof that payment happened; settlement shows in the recipient’s notes.
Withdraw (public). After proof verification the pool releases tokens to an external address. The destination, asset, amount and timing become public. Waiting before withdrawing and avoiding unusual amounts reduce correlation with an earlier deposit; they do not eliminate it.
8. Swaps and external DeFi
The swap module exchanges one supported asset for another while keeping shielded accounting correct: the input note is consumed, the output note is created, and conservation is checked in the swap’s own asset terms. Every quote shows the assets, the estimated output, the minimum received, the slippage limit, the fees and an expiry before the user authorises anything. Where a route is not atomic, the documentation states who holds funds in between and how they are recovered if the route fails.
Funds that leave the pool for an external protocol lose their privacy at the boundary. Lethe makes no claim that liquidity positions, lending positions or trades on other protocols are hidden, and no claim of protection against value extraction on those venues. On Elysium the first swap route is Uniswap v4 pools; others are added only with their own privacy description.
9. Shared treasuries
A shared treasury is a vault with a spending policy: the signers, the approval threshold, the allowed actions, the limits per action or per period, and how long an approval stays valid. An approval binds the exact action it authorises, including asset, value, destination, maximum fees and deployment, so a relayer or a signer cannot substitute a different payment under an old approval. Missing approvals cannot be replaced by anyone, relayers included.
Two limits to keep in mind. Policies are enforced inside the shielded system, so they protect funds that have already been shielded; a public multisig that funds the treasury still reveals its signers on the host chain. And a treasury’s members see the treasury’s history by design; selective disclosure (section 10) is how a treasury shows an outsider one payment without the rest.
10. Selective disclosure
The owner decides what to show. The smallest unit is a receipt for one payment: a reference, the status, and the details the owner chooses to include (asset, amount, date, counterparty). A receipt proves that one payment and nothing else. Stronger claims, such as “this vault held at least X on this date”, need an explicit disclosure proof generated by the owner, or viewing material scoped to the vault and period in question.
A reusable viewing key shows more than a receipt: whoever holds it can read the history it covers for as long as they keep it. Revoking an application’s permission stops future reads; it does not erase what was already received. The client labels each sharing option with exactly what it reveals before the owner confirms.
11. Privacy boundaries
The goal is less public linkage between ownership and activity inside the shielded system, not anonymity. Different parties see different things:
| Observer | Can see | Cannot see |
|---|---|---|
| Anyone reading Elysium | Deposits and withdrawals (address, asset, amount, time); that shielded actions happen; nullifiers | Who paid whom inside the pool, shielded balances, vault structure |
| Elysium sequencer | Every transaction it orders, and when; it can delay or censor during the single-sequencer phase | Sender, recipient and amount of a shielded action |
| Relayer | The transaction it submits, the fee it is paid, the submitter’s network address | Sender, recipient, amounts of the shielded action |
| RPC and indexer providers | Which addresses query which data, timing | Note contents (encrypted) |
| Swap venue | The swap it executes | Which shielded account ordered it |
| Recipient of a payment | The payment it received and what the sender chose to attach | The sender’s other activity |
| Holder of a viewing key | Everything the key’s scope covers | Anything outside it; cannot spend |
What weakens privacy: unusual amounts, deposits and withdrawals close together in time, rare assets, and low pool activity (a small anonymity set, which matters on a young chain). A compromised device or a leaked spending key defeats every protection above.
12. Relayers and service availability
A relayer submits a user’s already-authorised transaction and can pay the gas in exchange for a quoted fee, so a fresh shielded account can act without first funding an Elysium address. A relayer cannot change the outputs, charge more than the fee fixed in the proof, or spend anything on its own: the proof fixes all of that before the relayer sees it. Indexers help clients find their notes and check spent status; a client treats their answers as hints and verifies them against chain data.
Availability is part of the design. Note history can be rebuilt from the chain and the recovery phrase alone, and every action has a direct submission route that bypasses relayers and indexers. The direct route can expose more metadata (the submitting address pays gas publicly), and the client says so when it is used.
13. Fees and economic model
Revenue is payment for protocol execution and asset management, nothing else. The possible charges, each shown to the user before authorisation:
| Charge | When | Who sets it |
|---|---|---|
| Action fee | On a shielded transfer or withdrawal, as a share of the amount or a flat amount per action | Deployment parameter, published per release |
| Relayer fee | When a relayer pays the gas | Quoted by the relayer and fixed in the proof |
| Network cost | Elysium gas on public actions | The chain |
| Swap integration fee | On a swap routed through the module | Deployment parameter |
| Treasury service plan | Optional, for shared-treasury features | Published price list |
This paper sets no percentage; rates are deployment parameters published in the documentation and changed only with notice. Depositing into the pool earns no yield and the protocol never lends, stakes or otherwise deploys user principal. Pool reserves are always at least the sum of outstanding notes.
14. The LETHE token
Lethe plans a token, LETHE, on Elysium. Its purpose is to back the operators the protocol depends on and to let holders decide a small set of settings. Basic use of the protocol, shielding, spending and withdrawing, never depends on holding or buying it.
Staking behind operators. A relayer stakes LETHE to be listed, and signs a receipt for each transaction it accepts, promising inclusion by a stated block. If the transaction is not on chain by then, the receipt can be shown to the staking contract and part of the relayer’s stake is taken. Holders can stake behind a relayer of their choice; they share the relay fees it collects, after a commission that covers its gas, and they share its penalties. Fees are paid in the tokens users moved, and there are no token emissions. Indexers stake under the same rules. Staking introduces no new fee: it divides the relay fee described in section 13.
Use inside the protocol. LETHE is a supported pool asset, so it can be held and sent privately. In later phases relay and swap fees can be paid in LETHE at a lower price, and the hosted tools around shared treasuries are paid for in LETHE.
Listings and settings. In the last phase a governance contract becomes the pool’s administrator and so holds exactly its power: turning deposits of a token on or off. Proposing a token requires a LETHE bond and a published technical checklist; staked LETHE votes. The same votes set the staking parameters.
The token gives no ownership of pooled assets and earns nothing by being held. It places no charge on pool transactions, and no vote can move funds, block withdrawals or upgrade the pool. Supply, allocations, lock schedules, bond sizes, penalties and the contract address are published in the documentation before the token exists, so holders can verify what cannot move and until when. Until then no figure in circulation about LETHE is official.
15. Security and protocol controls
The security boundary covers the pool contracts, the circuits and verifiers, key management on the client, token adapters, relayers and the client software itself. Proof verification enforces ownership, value conservation, asset identity, nullifier uniqueness and replay resistance across deployments. Tokens with unusual behaviour (rebasing, transfer tax, transfer callbacks, issuer freeze or blacklist powers) are not supported until an adapter handles them explicitly, and the documentation names which ones are.
Administrative power is deliberately small. On the Elysium deployment the administrator is a multisig that can turn deposits of a token on or off. It cannot replace the verifier, block or delay withdrawals, upgrade the pool or move funds. The pool is not upgradeable, so any future power would need a new deployment, which is announced in advance, carries a review period, and is listed in the documentation with the addresses that hold it. Security problems are reported through the published disclosure channel; the response policy and any reward programme are published with the deployment.
16. Transparency and verification
A production deployment publishes, and keeps current: contract addresses with verified source on the Elysium explorer, the circuit and verifier versions with instructions to rebuild them, the administrator’s exact powers and the addresses that hold them, the fee schedule, every third-party dependency (relayers, indexers, RPC providers, swap venues), the recovery procedure for note history, and the known limitations in plain words.
Activity statistics exclude test data and exclude internal movements that would otherwise be counted as new deposits. Visible pool reserves on their own do not prove solvency, because liabilities are hidden by design; the documentation explains how to check that the pool’s reserve is never below the sum of outstanding notes using the published conservation rule.
Anyone can check the Elysium deployment with only the public chain: confirm the administrator’s powers from the verified source, tell shields, private transfers and withdrawals apart by their public footprint, and re-verify any proof against the verifier contract.
17. Roadmap and closing statement
| Phase | What ships | Status |
|---|---|---|
| 1 | Shielded pool on Elysium for HYPE (wrapped) and the first supported stablecoin; shield, vaults, private transfer, payment requests, withdraw; receipts | In preparation |
| 2 | Open relayer and indexer network with direct fallback, backed by staked LETHE; the LETHE token, shieldable in the pool; scoped viewing keys; disclosure proofs | After phase 1 audit |
| 3 | Swap module on Uniswap pools on Elysium; relay and swap fees payable in LETHE | Own security review |
| 4 | Shared treasuries with spending policies; team tools paid in LETHE | Own security review |
| 5 | Holder governance: token listings with a bond, staking settings | Rules published first |
Dates are published in the documentation when each phase has passed review, not before.
Lethe is a framework for managing supported assets on Elysium with more control over financial visibility. Its identity rests on four things: shielded accounting, vault organisation, verifiable authorisation and deliberate disclosure. It makes deposits and withdrawals no less public than they are today, and it does not promise that every action disappears. What it promises is that, inside the shielded system, the chain forgets: what you hold and who you pay is yours to show or not.