§ News

Auto-compounding LP: getting $HUBZZ off Bags

2026-06-28·Russ

Every trade on $HUBZZ pays a small fee. Right now those fees flow through a contract that Bags built and controls. The plan is to redirect them, permanently, into a pool that no one (including us) can ever pull from. This post explains what's locked, what's changing, and the one thing that has to stay trusted.

§ Where we are today

The dependency.

$HUBZZ launched on Bags. The token is free of mint and freeze authority, but the fee plumbing still runs through Bags' contract.

When someone trades $HUBZZ on its pool, the swap fee is captured by a Bags contract called Fee Share v2. The contract has a config account that records who can claim those fees. We checked that config on-chain. Here is what it says, today.

§ Fee programFEE2tBhC…1gqVKBags Fee Share v2. The contract that holds the fees until someone claims them.

§ Config account3XaRrnZY…vjS2The on-chain record of who controls fees for $HUBZZ.

§ Fee share100%Every dollar of swap fees flows to one wallet. No Bags split, no partner cut.

§ Claimer (immutable)D9w8EVbZ…vVLPJThe only wallet that can extract fees. Set at launch. Cannot be changed by anyone, including Bags.

Two things matter here. First: 100% of fees are routed to a single wallet (the "claimer"). Second: the claimer is locked into the contract by design. There is no instruction, anywhere, that lets us swap that wallet for a different one. That's not a bug we can fix on our side. It's the shape of the contract.

§ Why this is a problem

Trust shouldn't stay here.

One wallet, controlled by humans, sitting in the middle of every fee dollar is the exact shape we want gone.

§ Today

A wallet is the middleman.

The claimer wallet can take the fees and do whatever it wants with them. We've been honest about that, and so far the answer has been "burns and operations." But "you have to trust us" is not the story this project tells.

§ Goal

A contract is the middleman.

Replace the wallet's job with code that can only do one thing: take the fees and immediately deposit them into a pool that no one can ever drain. Once that's running, the project's liquidity grows on its own, forever.

flowchart LR
  P1["Trades on
Bags pool"] --> F1["Bags Fee
Share v2"] --> W["Claimer wallet
(humans)"]:::burn --> X1["Burns, ops,
discretion"]
  classDef burn fill:#13110F,stroke:#E56A35;

Today · a wallet decides where the fees go

flowchart LR
  P2["Trades on
our pool"] --> F2["Bags Fee
Share v2"] --> K["Narrow
keeper"]:::accent --> C["Crank
contract"]:::mint --> L["Permanently
locked pool"]:::mint
  classDef accent fill:#1B130E,stroke:#E56A35,color:#E56A35;
  classDef mint fill:#0B0C0E,stroke:#E56A35,color:#E56A35;

Goal · a contract decides, fees become permanent floor

§ The new shape

A pool that deepens itself.

We move from one Bags pool to a second pool that we create on Meteora's DAMM v2, owned by a contract instead of a wallet, with the liquidity permanently locked.

Claim the fees.

Pull the accumulated trading fees out of the Bags contract.

Balance them.

Convert what we got into the right ratio for the new pool's two sides.

Deposit them.

Add the balanced amounts into our own pool's liquidity position.

Lock them.

Mark the new liquidity as permanently locked. It can never leave.

flowchart TB
  K["Keeper signs
claim_user"]:::accent
  F["Bags Fee Share v2
— pending"]:::pool
  B["Balance to
pool ratio"]:::step
  D["Deposit into
locked position"]:::step
  L["permanent_lock
on new delta"]:::mint
  P["HUBZZ / wSOL pool
on Meteora DAMM v2"]:::pool

  K ==> F
  F ==> B
  B ==> D
  D ==> L
  L -.->|"floor grows"| P
  P -.->|"more trade fees"| F

  classDef accent fill:#1B130E,stroke:#E56A35,color:#E56A35;
  classDef step fill:#050608,stroke:#2A2C31;
  classDef mint fill:#0B0C0E,stroke:#E56A35,color:#E56A35;
  classDef pool fill:#15171B,stroke:#4A4D54;

The four-step loop · trusted boundary on the left, trustless on the right

§ The result

Every fee dollar earned by $HUBZZ becomes liquidity that no one can ever pull. Anyone can press the button to run the loop. The pool only ever gets deeper.

"Permanently locked" is a real on-chain state on Meteora's DAMM v2. Liquidity moved into that bucket cannot be withdrawn under any condition. There is no unlock instruction. Fees still accrue to the position, which is why the loop deepens.

§ What stays trusted

Honest about the one piece.

The downstream half (pool, position, lock, anyone-can-crank deposit) is fully on-chain and trustless. One step in front of it isn't, and we can't fix that.

§ The exception

Step 01 (claiming the fees) must be signed by the wallet that Bags wrote into the contract at launch.The Bags contract requires the locked-in claimer wallet to sign the claim instruction. We can't reroute that signature into a contract. The wallet has to sign.

§ How we contain it

A narrow keeper holds that signing key, and does nothing else.The keeper's only authority is to run the four-step loop. It cannot transfer fees anywhere besides the locked pool. The window of trust is "between claim and deposit", which is one transaction.

§ Eventually

The keeper key is published as a multisig, then time-locked.First step: multiple signers, no single point of control. Later: a public timelock so any change is announced in advance and visible to everyone.

§ Everything else

Steps 02 through 04 run as a single permissionless transaction.Anyone, anywhere, can call the contract that does the balance, deposit, and lock. There is no admin path. The contract holds no withdraw instruction.

§ What can't be undone

The locked actions.

Three of the steps below are irreversible on purpose. That's the feature, not a risk to talk around.

§ Permanent lock

Liquidity moved into the locked bucket on Meteora cannot be removed.This is the whole point. We seed small at first, prove the loop works, then crank in small increments so no single deposit can be off by much.

§ New pool creation

Meteora pools persist forever once created.Low-stakes irreversibility: the pool just exists. We get the parameters right before signing once.

§ Crank contract immutability

Eventually the contract that runs the four-step loop is frozen forever.Not on day one. We deploy it upgradeable with a multisig and a timelock. Months of stable operation later, we burn the upgrade authority so even we cannot change it.

§ Already done

Mint and freeze authority on $HUBZZ are gone.No new tokens can be created. No wallet can be frozen. This happened at launch.

§ Where we are

Status, honestly.

Three of five phases complete. The contract is written, audited, and proven against real mainnet state on a fork. Mainnet deployment is the next gated step.

§ Phase 1 · ReconCompleteOn-chain config decoded. Claimer, manager, and fee share confirmed against mainnet.

§ Phase 2 · BuildCompleteAnchor contract written. Five CPIs wired. 38 tests passing across unit, integration, and property-based.

§ Phase 3 · Audit3 passes21 findings closed across automated audits, including the Solana Foundation security checklist.

§ Phase 4 · DeployNextMultisig keeper. Create pool. Seed and permanent-lock initial liquidity. Transfer claimer authority to the contract.

§ Phase 5 · FreezeLaterMonths of stable operation, then the contract's upgrade authority is removed forever.

Track the migration as it happens at /lp — the live status page. Every number on that page is read directly from Solana mainnet.

§ The shape of the promise

Code, not a wallet.

Today, fees on $HUBZZ pass through a wallet we control. Tomorrow, they pass through a contract that can only deepen the pool. The wallet's job shrinks to one signature. The pool's depth grows on its own, forever.

§ One sentence

Trading fees stop being income, and start being permanent floor.

← All news