Locked liquidity
The position that holds a coin's entire float is owned by a contract with no way to give it back. What you get: a coin that cannot be rugged — not by its creator, not by us, not by anyone who steals a key.
Locked by absence, not by promise
Most "locked liquidity" is a timelock: a withdrawal function that refuses until a date. The function exists. Somebody holds the key. The date arrives.
Rhea DCL itself has no lock flag: a position's owner can always remove it. So on NEAR the lock is a property of who owns the position. Every coin's position is owned by the TerminalPad launchpad contract, and the launchpad's code simply has no path that removes it. Outside the fenced bond described below, the only liquidity call it ever makes on a position is:
remove_liquidity(position, amount = 0) — a fee claim: DCL pays out fees and removes nothingIt has no nft_transfer (DCL positions are NFTs), no other removal, no upgrade method. There is no execution path — for the creator, for the protocol owner, for us, for a compromised key — that withdraws that liquidity. Not "requires N signatures". Not "after 12 months". There is no path.
The key question. On NEAR an account can hold keys, and a full-access key can deploy new code over a contract. A lock by absence is only real if nobody can replace the code. The deployment's last step therefore deletes every full-access key from the launchpad account, irreversibly, after a rehearsal on mainnet. Until that step has been done, the lock is a statement about code, not yet a guarantee. Nothing is deployed yet, so this step has not happened.
You do not have to trust this. Once the launchpad is deployed (its account id will be in Architecture):
- list its keys on NearBlocks or with
near account list-keys <launchpad>— there should be none with full access; - read the launchpad's source (
near/contracts/launchpad) and look for calls to DCL'sremove_liquidity: every one outsidebond.rspasses an amount of zero.
What the launchpad can do
| Function | Who | Effect |
|---|---|---|
collect_fees | anyone | claims the position's fees (zero-amount removal) and books them 70/30 |
collect_extra_fees | anyone | the same, for a bonded coin's bid band |
claim_creator_fees | the creator only | sends the creator's booked share to the creator |
claim_protocol_fees | anyone | pushes the protocol's share to the treasury fixed at deployment |
bond / resume_bond | anyone | the one re-pairing, below |
withdraw_dcl_lt | anyone | if a bond's bid-band add failed, withdraws that tracker from the launchpad's DCL balance into the protocol's books (never a position) |
resume_launch / abandon_launch | anyone / the creator | continue a stalled launch; or, before anything reached the pool, refund the seed and burn the coin's supply |
set_paused | the launchpad owner | stops new launches; reaches nothing that exists |
None of the fee functions touches principal. Fees are earnings sitting on top of the position; the liquidity underneath never moves.
The one exception, and its guard rails
There is exactly one operation that moves a position: the bond, which removes the coin's position from the USDC pool and puts it back into the coin's tracker pool. It is the only place the launchpad's code removes liquidity, and it is fenced accordingly:
- it runs only through
bond, which anyone may call — never through a function that takes a destination; - once per coin: it requires the coin to be quoted in USDC, records its progress before anything moves, and allows one bond at a time per tracker;
- only onto that coin's own tracker pool, fixed at launch;
- the coin that comes out has no path out of the launchpad except back into the pool — or the burn of rounding dust, and a reserve of 1,000 units (about 10⁻¹⁵ of a coin) kept to move an empty pool's price back.
On Avalanche the whole migration was one transaction that reverted if anything failed. NEAR has no multi-contract transactions, so here the bond is a chain of recorded steps: one that fails leaves everything inside the launchpad, and resume_bond — callable by anyone — continues from where it stopped. A stalled bond does not strand liquidity; it waits.
See The bond.
What this does not cover
- Rhea DCL itself. The positions live inside Rhea's DCL contract. Its owner, Rhea's DAO (
ref-finance.sputnik-dao.near), can pause a pool and can upgrade DCL's code. The launchpad's lock stops us and anyone holding our keys; it cannot stop the venue it is locked on. That is the same shape of trust as any locker on any AMM. - The hedge. The lock is about the coin's pool. The USDC a bonded coin's tracker sends to the venue to hold its hedge is a different thing: it leaves NEAR through NEAR Intents for an account on Hyperliquid that a TerminalPad contract controls, and comes back the same way. Risks & security says plainly what that means.