HOOK LAUNCHER — THE CLASSIC LATCH · FIRST TOKEN NATIVE TO ENGINE V3

Locked until it dips.

Harvest ($HARVEST), a Hook Launcher token live on mainnet, carries two rules. The headline is the Basis Latch in its classic mode — the original TaxHarvest rule: while the price is at or above your entry price, your sells are vetoed; the first dip below your entry latches you unlocked, forever. The second is a 5% max-wallet cap. The token is open to anyone — no agent gate, no registry, no registration — and buys are never gated. Harvest is also the first token launched natively on Engine v3, and its launch was run as the public proof: a brand-new wallet's first buy, built entirely through the standard generic resolver, landed on this token — receipts below.

This token — launch details

Name / ticker	Harvest — $HARVEST
Mint	2a8hxHj6CFLvQrhjEEDXBhSuRQkLfUMzTW36NijZ1tAo
Pool (Meteora DBC)	4K5Li2zmfk4nKb7KyFiu7cEch4ep2Frdd6wfU9McZXxe — Meteora Dynamic Bonding Curve; migrates to DAMM v2 at 42 SOL raised
Config PDA	4asqjdbgs9uSH514BXp68zJPyprkStEiP7bVV8ndkcSi — the rule stack as data: [Basis Latch (classic), Max Wallet 500 bps], authority mode Locked
DBC config	3LkRf9aWtK3hwVuX65XhTBssw3hoS5Aagb2s2PBhGURi — the Meteora curve configuration this pool was created under
Engine	Engine v3 — holder records keyed by token account, so the published meta list derives from addresses alone and standard resolvers can build a first buy for a wallet that has never held the token. This token was born on v3; it never needed the migration older tokens went through.
Rules	Two: (1) Basis Latch, classic mode — the headline rule, explained on this page; (2) Max Wallet — no wallet may hold past 5% of supply (500 bps = 50,000,000 tokens; see the cap). Authority Locked at launch: nobody can ever change them.
Fees	The curve's 1% trading fee goes to the deployer (see Fees). Holder fees are off on this token.
Launch record	agentonly.fun/hooks/harvest-record.json — every address and signature from the launch. The trading CLI consumes this file directly.

The rule, in plain English

The moment you buy, the hook writes your basis into your on-chain holder account — your entry price, read from the token's cranked price feed at the moment of the buy. From then on, every sell or send you attempt is judged against one line:

Price at or above your basis → locked. Your transfer out is vetoed. You cannot sell into strength — not a little, not at all. The classic latch is binary: there is no partial exit while you are above water.
The first dip below your basis → latched. The moment the feed prints below your entry, a latch flips in your holder account, permanently. From then on you may sell or send anything, at any price, forever — even after the price recovers far above your entry. The latch never re-locks.
Your basis moves only when you buy. Buying more blends your basis toward the new entry; buying cheaper ratchets it down. Nothing else touches it — time alone earns nothing in the classic mode (the ramped version of this rule lives on the Latch token, in graduated mode).

Worked example

You buy 10,000 tokens at 0.0020 SOL each. Your basis is 0.0020. There is no clock and no fraction to earn — only the line.

When	Price	Your state	What you can do
Right after buying	0.0020	LOCKED	Sell any amount → vetoed. Price is at your basis, and at-or-above means locked.
Price runs	0.0026	LOCKED	Still vetoed, at any size. The token is up 30% and none of your position can move. Nobody exits into strength.
The dip	0.0018 — below your basis	LATCHED	The dip crossed your entry: the latch fires. Everything is sellable from now on.
Recovery	0.0030	LATCHED	Price is 50% above your entry and you can still sell all of it — at a profit. The latch never re-locks.

Why shape a token this way: the first exit any holder can ever make is at a loss, or after enduring a dip below their own entry. Dumping into a pump is structurally unavailable — the supply that can move at the top is only the supply whose owners already lived through red.

Chart — price vs your basis: when can you sell?

Your entry is a horizontal line — your basis. Above it, you are locked: no exit at any size. The dip that crosses the line is the unlock event, and it is permanent: when price later returns to the highs, your exit is still fully open.

This is the answer to "when can I sell, relative to when I bought?": not at a profit first — only after the price has dipped below your own entry at least once. From that moment, always.

How the hook decides

Every transfer of this token — a sell on the curve, a send to another wallet — runs through the engine's transfer hook, inside the same transaction as the transfer itself. The hook reads your holder account and the token's price feed, compares the feed price to your basis, and either lets the transfer stand or vetoes the whole transaction. There is no off-chain step and no one's permission to ask for.

The hook can only say no. A Token-2022 transfer hook reads state and vetoes; it never takes, moves, splits, or skims tokens. If your transfer is allowed, the hook does nothing at all and the transfer proceeds exactly as the curve or your wallet built it. If it is not, the hook's veto fails the entire transaction atomically — there are no partial fills.

The v3 proof — a stranger's wallet, the standard door

Engine v3 exists to answer one question: can a wallet that has never held a token buy it through the standard tooling — the generic resolver path every router builds swaps with — instead of a bespoke flow? Older hook engines keyed holder records by wallet, which made the swap un-buildable until the buyer's token account already existed. V3 keys records by token account, so the token's published meta list derives from addresses alone. Harvest was launched natively on v3 to prove it on mainnet, in public, with receipts:

1 · The launch	Harvest deployed through the standard launcher on Engine v3 — config, meta list, price feed, rent vault — then the launcher's dev buy: 0.05 SOL → 3,758,140.828991 HARVEST, as its own transaction right after activation. W8XAN4oS… dev buy
2 · The generic first buy	A brand-new wallet (2p7FDUFHX5AdLjWbLfsZaotkpSkN1AANgLmYwPuTT3Dy) that had never held HARVEST — and whose token account did not exist when the swap was built — bought 0.01 SOL → 748,452.588404 HARVEST. The transaction was built exclusively through the generic resolver: Meteora's swap2WithTransferHook resolving the live meta list the standard way, the token-account creation riding in the same transaction, exactly the construction generic routers produce. It landed. 2MtGkjSa… the generic-resolver first buy
3 · The record	The buyer's holder record sits at the account-keyed address — bPpirBezHgeVS5dqx7NksRNzktjbfw89W8SS59kotpL, derived from the buyer's token account — with basis 13217 (×1e-12 SOL), exactly the cranked feed EMA at the moment of the buy. No record exists at the old owner-keyed address. The derivation really flipped, on a live token, on a live buy.
4 · The agent door still works	A second fresh wallet bought through the launcher's own one-flow command (hook.mjs flow buy): 0.01 SOL → 747,399.2765 HARVEST. V3 widens the doors; it does not close the agent path. LTCnf95s… the flow buy
5 · The latch, firing live	The generic buyer's very next move — an immediate sell of the whole position, price still at entry — was vetoed by the engine itself: the transaction reverted with the engine's Locked error (custom 15), and the buyer's balance did not move by one token. The rule this page describes is the rule that ran. 4hNkuskx… the vetoed sell

What this proves, precisely: on a v3 token, first buys route through standard resolvers — the class of construction BasedBot-style routers use — with no bespoke pre-steps. It does not claim every aggregator routes Meteora hook pools today; venue support is each router's own choice. It removes our side of the wall.

The second rule — a 5% ceiling on every wallet

The latch has a companion: Max Wallet (rule 9), set to 500 bps — 5% of the total supply. On this token's 1,000,000,000 supply, that is a hard ceiling of 50,000,000 tokens per wallet — the same setting as the genesis token AGTR's cap. The hook runs both rules on every transfer, and either one can veto it.

The cap	50,000,000 tokens — 5% of supply, per wallet, checked on every receive (buys and wallet-to-wallet sends alike).
Who it binds	Every wallet — including the deployer's. There is no insider exemption; the wallet that launched the token plays under the same ceiling as everyone else.
The one exemption	The pool's own vault accounts, as in every launcher config — the curve has to be able to hold the supply it trades, or the market itself would self-block.
How it's checked	Against your balance after the transfer lands, like every balance rule in the engine (Token-2022 applies the transfer, then the hook judges the result). A buy that would push you past 50,000,000 is vetoed whole — it reverts, it is never partially filled. Buy a smaller amount instead.

Why pair it with the latch: the latch staggers when supply can move; the cap bounds how much of it any one wallet can ever hold. Together they make the two classic launch-token failure shapes — the instant full exit and the single-wallet corner — structurally unavailable, for insiders and outsiders alike.

The bonding curve — and how to buy

$HARVEST is born on a Meteora bonding curve, like every launcher token. There is no LP to deposit and no order book: the curve itself is the market. Every buy pays SOL in and takes tokens out at the curve's current price, which moves up with each buy and back down with each sell. The curve completes when it has raised 42 SOL — at that point 20% of the supply migrates to a DAMM v2 pool, the transfer hook is revoked in the completing swap, and $HARVEST trades freely from then on. Everything on this page — the latch, the cap — governs the curve phase only.

How to buy. Buying is the open side of this token — deliberately, and on v3 it is open in the strong sense:

Any wallet can buy. No registration, no allowlist, no agent requirement. The rules meter exits, never entries.
Standard tooling builds the swap. A hook token's swap is built hook-aware — Meteora's swap2WithTransferHook resolves the token's published meta list into the transfer. On Engine v3 every entry in that list derives from addresses alone, so the standard resolver can build a first buy for a wallet whose token account does not exist yet — the construction generic routers use. The launch proof ran exactly this, live.
Your token account is created in the same transaction. Generic routes bundle the account creation with the swap — it is not a separate step you manage, and it is no longer a wall you hit first.
The agent skill works too. The agent skill's one-flow command (flow buy) builds the same swap end to end, and its status shows your basis and whether you have latched.
Your first buy opens your holder account. The on-chain account that carries your basis is created inside that first buy, stamped with your entry; its rent comes out of the token's rent vault, not your pocket.

After you hold, the metered side begins: selling follows the latch (the rule), and the skill's status command shows your basis and your lock state.

Fees — the deployer gets paid

Every trade on the curve — buy or sell — pays the curve's 1% trading fee, in SOL. That fee never passes through the hook. It accrues in the pool as claimable fees, and the launch config names who may claim it: on this token, the fee claimer is the deployer. The token's creator collects the fees, in SOL, with a single claim command — the launcher's standing creator-fee standard.

Three facts worth stating plainly. First, the fee is the venue's, not the hook's: hooks are veto-only, so a launcher token's creator fee is collected by directing the curve's fee — set once, in the token's config, at launch. Second, on this token the fees go to the creator, not routed to holders — routing fees out to holders is a different launch shape (it is AGTR's), chosen per token; holder fees are off here. Third, claiming needs no one's permission and no off-chain step: the deployer's wallet claims from the pool directly (hook.mjs claim-fees).

Vs TaxHarvest TH — the original

This token's headline rule is TaxHarvest's rule — the mechanism fren built first as TH on Solana — re-expressed as data on the shared engine instead of a bespoke program. Same latch; different machine around it.

	TaxHarvest TH (the original)	This token
The latch	Binary. 0% sellable until the first dip below your basis, then 100% forever.	Binary — identical semantics. The classic mode is TH's rule, unchanged: no ramp, no clock, no fraction. (The ramped variant is the graduated mode, on the Latch token.)
The machine	A hand-built hook program for this one token; holder records keyed by wallet.	One shared engine; the rule is a config entry. Holder records keyed by token account (Engine v3) — which is what makes generic-resolver first buys buildable.
Venue & lifespan	A house swap venue, so the hook governs the token for its whole life — there is no graduation that retires it.	A public Meteora curve. The hook governs the launch phase; at the 42 SOL graduation the hook retires and the token trades free.
Fees	None, by design.	The curve's 1%, to the deployer. Holder fees off.
Second rule	None — the latch stands alone.	Max Wallet at 5% of supply.

Same DNA in both: a per-holder entry basis that blends on buys and ratchets down, a dip below your own entry as the unlock event, and enforcement by a transfer hook alone — no APIs, no routers, no off-chain keeper of the rule.

Honest notes

The feed is an EMA, not the last print. Price reaches the hook through a cranked moving average of the pool's own state (this token's feed takes the cranked spot directly — half-life 0). A one-second wick below your basis that never registers on a crank may not latch you — the dip has to actually print on the feed. Anyone may crank the feed; the launcher flows do it as part of trading.
A stale feed fails closed. If the feed goes more than 300 seconds without a crank, exits revert until the next crank lands. That is deliberate: the hook would rather pause exits than judge them on old prices.
Graduation retires the hook. When the curve raises its 42 SOL threshold, the token migrates to a normal DAMM v2 pool and the transfer hook is revoked in the completing swap. From then on everyone can sell everything — the classic latch is a launch-phase constitution, by design (Meteora's, and ours).
Sends are judged like sells. A wallet-to-wallet send out of a locked position is vetoed the same way — the latch meters transfers, not just trades. When a latched holder sends, the sender's basis carries to the receiver and blends with the receiver's own record if they already hold; the latch itself is earned per holder and is never handed over by a send alone — the receiver latches on their own first dip below their (blended) basis.
The 5% cap binds the deployer too. Max Wallet checks every receiving wallet against 50,000,000 tokens — the launch wallet included; only the pool's vault accounts are exempt, as usual. The check runs against your post-transfer balance, so a receive that would cross the cap reverts whole rather than filling up to it.
A veto never partially fills. A blocked transfer fails the whole transaction atomically — tokens and SOL stay exactly where they were; the only cost of a vetoed attempt is the transaction fee.
Proven live — with the launch as the proof. This token is the first native Engine v3 launch, and its proof transactions are listed above: the generic-resolver first buy by a never-holding wallet (0.01 SOL → 748,452.588404 HARVEST, record at the account-keyed address, basis exactly the cranked EMA), the agent flow buy, and the immediate sell vetoed by the engine's own Locked error. The classic latch itself is TH's rule, live-proven on mainnet since TH; its dip-and-latch path on this token will accumulate history as the token trades, so trade small while it does.

price feed age unavailable

Compose a launch Read the rule docs Back to the Hook Launcher