How LockOn works.

Purpose

Pons V2 permanently locks launch liquidity, fixes token supply and freezes fee settings at launch. The tokens bought by the public deployer inside the launch transaction can still move from that deployer's wallet. LOCKON makes that opening position time-bound and publicly verifiable.

LOCKON does this with one contract, DevLock, and a browser-direct website. Verification reads Robinhood Chain directly and stores no verdict. A narrow media service accepts optional token-logo images, normalizes them to public WebP files and receives no wallet state, signature, ETH, transaction or verification result.

Launch path

1. The DEV connects an EVM wallet on Robinhood Chain.
2. The DEV may use a logo URL or upload PNG, JPEG, WebP or GIF. The media service validates and converts the image, then returns its public URL.
3. The page reads the current Pons factory gate, forwarder, launch fee, configuration and economics pin.
4. The wallet calls the official Pons launchAndBuy forwarder.
5. The launch uses config 0 and the selected paired asset; Creator Wallet defaults to ETH. The DEV sets the creator tax within Pons limits; the extra exemption list is always empty.
6. The opening buy recipient is DevLock.
7. The Pons factory records the connected wallet as deployer.
8. The same wallet calls DevLock.attach(token, duration).
9. DevLock records the token amount and unlock timestamp.

Distribution asset

Creator Wallet uses ETH by default in the LOCKON interface. Holder Sharing reveals a searchable distribution-asset selector with ETH, stock tokens and other assets from the official Pons catalog. The selected asset is checked live for Pons approval, non-zero economics, contract code and matching decimals before launch.

The Pons pair asset and fee recipient are independent contract settings; showing the selector only for Holder Sharing is a LOCKON interface choice. The selected asset is fixed at launch and denominates trading, the opening buy and future creator fees. MU with Holder Sharing therefore requires MU for the opening buy and distributes future creator fees in MU. It does not create a stock basket.

For native ETH, transaction value is the launch fee plus the opening buy. For ERC-20 pairs, the wallet authorizes only the opening amount to the current Pons forwarder and pays the launch fee in ETH. An existing smaller non-zero allowance is reset first. This can add one or two approval signatures; an existing sufficient allowance needs none. All launches keep the opening recipient fixed to DevLock and extra exemptions empty.

Pons official custom pairs documentation ↗

Creator fee routes

Creator Wallet sends creator fees and creator tax to the selected wallet. Pons buyback remains an optional launch setting for this route.

Pons Official · 100% Holder Sharing starts with the connected wallet as the fee recipient and buyback disabled. After launch and attach, the same wallet signs createFor(token) on the official Pons Holder Fee Manager and transferCreatorFeeRecipient(token, distributor) on the Pons factory. The four-signature flow becomes active only after the manager mapping, distributor token binding and current factory recipient all agree. It then routes all future creator fees and creator tax pro rata to token holders.

Interrupted follow-ups resume from the last confirmed stage without relaunching. Holders claim through the token page on Pons. The official manager and distributors are upgradeable Pons contracts, and Pons retains its timelocked recipient-override path.

DevLock contract

DevLock accepts tokens launched by one immutable Pons V2 factory. It has no owner, administrator, upgrade, pause or rescue function.

The public deployer may attach the opening balance once. The minimum duration is read from MIN_LOCK() on the deployed contract. The attached position can be withdrawn only by the factory-recorded deployer after its unlock timestamp.

Any token holder may create a separate holder position. Holder positions belong to the wallet that transferred them and cannot be presented as an opening-position lock.

Lock an existing token

Open Lock an existing token, load a Pons V2 address and connect the wallet holding its tokens. Choose an amount and a whole number of days. The minimum is read from DevLock. If needed, approve the exact amount, then confirm the lock transaction.

The original factory-recorded deployer is labelled DEV later lock. Other wallets are labelled Holder lock. These deposits use the contract's holder position and are never counted as an opening-buy lock. Adding tokens extends the entire position to the later unlock time. At expiry, the same wallet withdraws its tokens.

Market indexes both DevLockAttached and HolderLocked, with one record per token. It reads each owner's current position, separates opening, DEV later and other-holder amounts, and excludes expired tokens from active share. Next unlock is the earliest expiry among active positions. Historical records remain after withdrawal. A token may carry multiple lock types.

Extra exemption warnings and opening-buy checks remain separate. Missing or incomplete reads never become zero or green. More than 256 later-lock owners or a failed position read leaves aggregate amounts incomplete.

Verification model

For each token, the browser pins one Robinhood Chain block and reads every state value at that block.

• Pons factory launch metadata
• Token name, symbol, supply and public deployer balance
• DevLock factory binding, minimum duration and position data
• The first CurveBuy event from the launch curve
• Every immutable SnipeTaxExempted event
• Any pending creator-fee-recipient proposal
• The official Holder Fee Manager mapping and registered distributor's token() binding

The expected unique exemption set uses the public deployer, the initial creator fee recipient and the first CurveBuy recipient. Addresses outside that set are reported as extra exemptions, even after the creator fee route changes.

Result states

GREEN

DevLock is validated, the opening position is active, the first buy went to DevLock, all expected exemption events exist and the extra count is zero.

YELLOW

An active lock has a different first-buy route or extra exemptions, or the recorded lock period has expired.

GRAY

Site activation is pending, there is no active attached position, the token is outside Pons V2 or a required read is incomplete.

Creator fee routing is reported separately from the opening-lock result. Holder sharing is active only when all three official route reads agree.

Scope

LOCKON describes the opening position bought by the public launch wallet. It cannot stop a DEV, related party or any other trader from buying and selling through another wallet. It does not evaluate token price, identity, offchain promises or future trading behavior.

$LOCKON demonstration

$LOCKON is planned as the first token launched through the complete path. Its planned opening position duration is 180 days and its extra exemption list is empty. DevLock is deployed, with exact source matches confirmed by Sourcify and Blockscout. The LOCKON token has not launched. The site is connected to the deployed DevLock.

Release boundary

Before launch, the release process must re-read factory.launchForwarder() and factory.canLaunch(launchWallet). The DevLock deployment, verified source link, website configuration, media storage and complete fork gate must also be confirmed before any mainnet transaction. Holder sharing additionally requires live validation of the configured Pons Holder Fee Manager.