How it works

Lamprey is a protocol treasury with one instruction: take the fee from every trade, convert it, and buy the smallest company it can verify on Nasdaq. When that position is filled, it moves to the next smallest. It does not sell.

The name is the mechanism. A lamprey attaches to something much larger than itself and feeds without asking. The treasury attaches to trading volume and feeds on the fee.

Phase 1, which is what this site shows, is the part that can be built without touching anyone's money: the symbol directory, the verification pipeline, the queue, and the public record. The contracts are written but unaudited, and the brokerage account is not yet funded.

Every fee is routed to FeeVault, a contract, on receipt. It is never held by an externally owned account, and there is no code path in which a private key can move the balance to an arbitrary destination.

FeeVault exposes exactly one outbound function, and it can only be called by BiteController after a committed bite has cleared its timelock. The vault has no withdraw, no sweep, no rescue, and no upgrade path. If the controller is ever paused, the ETH stays where it is.

Conversion to dollars happens at the off-ramp, which holds no balance between bites. The balance shown on the dashboard is the vault balance, priced at the last recorded ETH mark, not an internal accounting figure.

A bite has three steps and a mandatory wait between the second and third.

• commitBite(ticker, sizeUsd) publishes the intended target and size onchain. The queue row it refers to is already public, so the commitment can be checked against the published verification before anything moves.
• A 48-hour timelock runs. Nothing can execute inside the window. The commitment cannot be edited, only cancelled, and a cancellation is recorded like any other event.
• executeBite(commitmentId) releases the funds, the order is placed, and the fill is written back as a receipt: shares, average fill price, the brokerage confirmation number, and a receipt hash stored by ReceiptRegistry.

The 48 hours exist so that a bad commitment is visible before it is irreversible. If a target fails re-verification during the window, the commitment is cancelled and the row returns to the queue or to the rejected list.

The universe is the Nasdaq symbol directory, currently 5,594 symbols. From that, the pipeline keeps domestic common shares only. Units, warrants, rights, depositary receipts, closed-end funds, and exchange-traded products are removed before anything is verified.

What survives is filtered to a verified market capitalisation below $25M, then sorted ascending. The smallest company the pipeline can stand behind is always next. Of the 640 symbols whose share count was verified against a filing, 392 are in the queue today. The rest were rejected, and those the screener also placed under $25M are listed, with both cap figures and a reason, under the queue.

Position in the queue is determined by verified cap, not by the Lamprey Score. The score describes how confident the pipeline is in a row, not how much it wants to own it.

Market cap is computed as last close multiplied by shares outstanding, where shares outstanding is read from the company's own SEC filing — the XBRL cover-page tag on the most recent 10-K or 10-Q — and never from a data vendor.

That figure is then cross-checked against a commercial screener. The cross-check multiple is the screener's cap divided by the verified cap, and it is published on every row.

A row is rejected when any of the following is true:

• The cross-check multiple falls outside 0.5× to 2.0×, which usually means a stale share count or an unhandled reverse split.
• No shares-outstanding tag exists in the filing's XBRL cover page.
• The most recent filing is more than 400 days old.
• The verified cap lands above the $25M line, whatever the screener claimed.
• The security is not a domestic common share, or trading is halted.
• Median session volume is too thin for a position to be built without moving the price.

Rejections are published rather than discarded, with both numbers side by side, because the gap between the screener and the filing is the most useful thing the pipeline produces. The smallest verified cap in the queue today is $710K.

Six factors, each rated one to five, each multiplied by a weight. The weights sum to twenty, so the score runs from 20 to 100. It is a confidence measure, not a valuation.

A low score does not remove a company from the queue. It records that the pipeline had to work harder to stand behind the number, and it is shown next to every row so the reasoning is checkable.

There are no holder rewards. There are no dividends. There are no redemptions. There are no buybacks. None of these are planned, and none are missing features.

The reason is narrow and specific. A vehicle that pools contributions and passes returns back to contributors looks like an unregistered investment company, and a token that entitles its holder to a share of acquired assets looks like a security. Lamprey avoids both by never creating the entitlement in the first place: the treasury buys, holds, and publishes, and the token conveys no claim on anything it holds.

There is also a hard line at 5% of any issuer's outstanding shares. Crossing it triggers a Schedule 13D or 13G filing obligation and a set of ongoing duties the protocol is not built to carry. Position sizes are capped so the line is not approached, and a company whose float is small enough that a standard bite would cross it is rejected rather than partially filled.

By hand, in two transactions, and the order matters. The token was launched on Pons from the operator's own wallet — a normal launch, paired against native ETH, with the creator tax set to 10%, which is the maximum the factory allows. The vault did not exist yet, so the launch named that wallet as the creator fee recipient. The vault was then deployed against the token and curve produced by that launch, and the launcher called transferCreatorFeeRecipient(token, vault) on the factory to hand the role over.

The vault has no launch function and no way to make itself the creator. That is a deliberate reduction: launching from inside the contract would have meant trusting it with the launch fee, the opening buy, and a set of parameters that can never be corrected. Doing it by hand means the launch can be inspected on-chain before a single line of vault code is deployed, and a mistake in the launch costs a relaunch rather than a stranded vault.

There is an honest gap in this. Creator tax that accrued between the launch and the handover belongs to the wallet that launched the token, not to the vault. The escrow credits whoever is the recipient at the moment a fee is booked and there is no back-crediting, so nothing from that window can be claimed into the vault later. It is not vault money and this site has never counted it.

You do not have to take any of that on trust. The vault exposes isCreator(), which reads the recipient back out of the curve and compares it to itself, and the custody panel shows CREATOR NOT YET TRANSFERRED for as long as it returns false. The handover is a public transaction; the factory's getLaunchedToken and the curve's owndeployer slot both confirm it independently.

Yes, partly, and it is worth being precise about how far it goes. The token was launched on Pons and its creator role handed to the vault, and the Pons factory owner can move a launch's creator fee recipient with setCreatorFeeRecipient. That call does not take effect immediately: it opens a proposal with a three-day timelock and a three-day window to execute, and the proposal is public on-chain the moment it is made.

What this reaches is future fee accrual. It cannot touch ETH already claimed into the vault, and it cannot touch a balance already credited to the vault inside the escrow, because the escrow only ever pays the account that calls it. A redirect changes who earns the next fee, not who owns the last one.

The vault reads any pending change straight from the factory and this site shows it, so the three days are not quiet ones. The vault itself cannot hand its creator status away: the only function that would let it, transferCreatorFeeRecipient, is callable solely by the sitting recipient, and the vault has no code path that emits that call.

A fixed externally owned account, controlled by the operator, and the only address the vault can pay. It is set once at deployment and is immutable; there is no function anywhere in the vault that writes to it, so it cannot be changed by the operator, by a governance vote, or by anyone else. Changing it would mean deploying a different vault.

Its job is to convert released ETH to dollars and place the order with the brokerage. That step is off-chain, and it is the point where the trail would otherwise go dark, which is why the brokerage confirmation is the proof of what happened next. Each bite's confirmation is stored, hashed, and the hash is written on-chain in receipt(). Anyone can check the published document against the hash the vault recorded.

The honest limit: the vault can prove ETH left it, when, and to where. It cannot prove what an off-chain counterparty did with it. The confirmation and its hash are what close that gap, and they are only as good as the brokerage that issued them.

Exactly four things, and no more:

• commitBite — schedule a release, capped by the per-bite maximum and by the vault balance, and starting a 48-hour clock.
• cancelBite — withdraw a scheduled release before it executes. The ETH stays in the vault.
• receipt — record what an executed bite actually bought. Writes a record and moves nothing.
• proposeOperator — nominate a successor, who can accept only after the same 48-hour delay.

What the operator cannot do:

• Change the off-ramp, the delay, or the per-bite cap. All three are immutable.
• Send ETH anywhere other than the off-ramp. There is one transfer statement in the contract and its destination is fixed.
• Stop a committed bite from executing by doing nothing. executeBite is permissionless once the delay has passed, so anyone can complete it.
• Withdraw, sweep, rescue, or upgrade anything. None of those functions exist.

The operator is a paid party: it receives its share automatically at claim and still cannot move vault ETH anywhere but the off-ramp. Losing the operator key freezes new bites and stops fees being claimed; it does not put the balance at risk.

Half of every claimed creator fee. The share is 50%, it was fixed when the vault was deployed, and it cannot be raised — it is an immutable set in the constructor, the constructor rejects anything above 50%, and no function in the contract writes to it. The only way to change it is to deploy a different vault.

It is taken inside claim(). The vault measures how much ETH actually arrived from the Pons escrow, forwards the operator's share in the same transaction, and keeps the rest. The split rounds down, so any odd wei stays with the vault rather than the operator.

The other half stays in the vault and can only leave through a bite: committed, timelocked for 48 hours, and paid to the fixed off-ramp. So the operator is paid automatically and cannot touch the remainder.

This is the second of exactly two ways ETH leaves the vault. There is no third, and both are pinned by tests that run every wei of inflow and outflow through sixteen thousand randomised operations.

The pipeline refreshes on weekdays after the US close. Prices come from that session, share counts from whatever filing was most recent when the run started, and the queue is re-sorted before it is published.

Every page carries the timestamp of the run that produced it. The data currently shown was built at 2026-09-02 15:07 UTC. Nothing on the site is a live quote and nothing updates between runs.

Verification is repeated before a bite executes, not only when a company enters the queue. A row that has been in the queue for weeks is re-checked inside the timelock window.

This table is read from the protocol's configuration record, not written into the page. Before a deployment exists it lists the contracts as pending; on launch day the deployed addresses appear here and in the custody panel without the site being rebuilt.

• The contracts have been statically analysed and tested, not independently audited. Until a third-party audit is published, treat every onchain claim on this site as a statement of intent.
• Pons can redirect future fees. The Pons factory owner can move the creator fee recipient away from the vault after a three-day timelock. ETH already in the vault is unaffected, and any pending change is shown on this site, but the fee stream is not unconditionally permanent.
• Operator key loss strands the balance. Without the operator key no bite can be committed and no successor can be proposed, so the ETH sits in the vault indefinitely. It cannot be stolen, and a bite already committed can still be executed by anyone, but nothing new moves.
• The brokerage and legal layer is off-chain. The account can be frozen, closed, or required to unwind a position, and the protocol has no onchain remedy for any of it. The confirmation hash proves what the brokerage reported, not that the brokerage will keep operating.
• Micro-cap liquidity cuts both ways. At these sizes the act of buying moves the price against the treasury, a position can take many sessions to build, and there may be no bid at all on the way out — which matters because the treasury does not sell.
• Stock tokens on Robinhood Chain can decouple at the weekend. The underlying equity market is closed while the chain keeps trading, so a tokenised price can drift from the last real close and only reconcile when the market reopens. Verification runs on filings and closing prices, not on weekend quotes.
• Companies this small can fail. A position can go to zero, and the treasury does not sell, so it will hold that outcome.
• Thin liquidity means the act of buying can move the price against the treasury, and a position may take many sessions to build.
• Verification depends on filings being correct. A company that misstates its share count will misstate its cap, and the pipeline will repeat the error.
• Delisting, halts, and going-private transactions can strand a position with no way to exit.
• The regulatory treatment of a structure like this is not settled. The design avoids the obvious hazards; it cannot guarantee how a regulator will read it.
• The off-ramp and brokerage steps are off-chain and depend on counterparties who can freeze or close an account.
• Fee revenue is not guaranteed. If volume stops, the treasury stops growing and no further bites occur.