How KNOKQ works

What is KNOKQ

A market only exists after a stock price barrier is crossed, and revenue from trading it funds the next round.

KNOKQ is a stock-triggered token launch protocol on Robinhood Chain. A creator arms a future token behind a Stock Token price barrier. Until a valid observation of that price crosses the barrier, there is no launch and no token.

Once the barrier is crossed, the trigger latches permanently and the token is born on the market's launch venue, which is Pons v2 by default. From then on, revenue that reaches the market contract loads the next cycle, which buys the token back and burns it when the next barrier is crossed.

Three rules everything else follows

Latch first

A qualifying stock event and the venue call that follows it are separate facts. A crossed barrier latches and stays latched through a venue failure, a guardian pause, a price reversal, or expiry.

Received, then loaded

Only value that has actually arrived at the market contract and been allocated counts as LOADED. Fees sitting on a curve or in a hook are PENDING VENUE SWEEP and are never counted as spendable.

Permissionless

Every state-advancing call, from latching a trigger to executing a tranche, is open to any caller. KNOKQ's keeper is automation that sends these calls promptly, and it holds no special permission.

Arming a market

A creator sets a barrier, direction, expiry, and quote asset, and the factory locks the terms on chain.

A creator picks a Stock Token from the registry, a direction (above or below), a barrier price, an expiry window, a cycle step, and a quote asset. The KNOKQ factory validates the asset binding, the metadata and its sizes, the cycle step, the expiry window, the quote asset, a live oracle read, the barrier distance, and the default venue's launch configuration before it arms anything.

The barrier is set in share terms and converted to an economic barrier once, using the multiplier in effect at arm. The factory then escrows the launch fee and any creator preload, clones the market contract, and registers it with the launch router against the factory's default venue. The market keeps that venue for life.

The stock trigger

A trigger latches only after a set of core checks and a policy both agree the observation is valid.

Every trigger evaluation, whether for birth or for a cycle, runs through the same engine. A set of core checks cannot be relaxed by any policy: the asset binding still matches what was armed, the answer is positive, the oracle is not paused, the multiplier is valid, the minimum arm age has passed, the market has not expired, and the economic-barrier comparison holds.

Only an observation that clears all of those is handed to the bound trigger policy, which adds freshness, session, and confirmation rules. Anyone can call the function that evaluates a trigger. Once a barrier is validly crossed, the latch is permanent. It survives a venue failure, a guardian pause, a price reversal, and expiry.

Economic barriers

The barrier is set in share terms and enforced in economic terms, so splits and dividends cannot trigger it by themselves.

A Stock Token feed reports a continuous token value. A corporate action like a split changes the ratio between that token value and a share price, but the feed itself does not move. If a barrier compared raw feed price to a fixed share number, a scheduled split could cross it with no real market move at all.

KNOKQ avoids this by normalizing with the multiplier snapshotted at arm. The feed price is converted to a share price using that fixed multiplier rather than whatever multiplier is current, which makes the barrier split-invariant. The displayed barrier restates in current share terms whenever the multiplier changes, and dividends make the displayed barrier drift down slightly because dividend reinvestment is built into the multiplier.

When a token exists

There is no token, no price, and no address commitment until birth settles on chain.

An armed market has no token, no price, no market cap, and no holder count. It is shown as a barrier and a distance to it. Nothing is displayed as if a token already existed.

Before birth, KNOKQ can compute a PREDICTED ADDRESS for where the token would deploy under the Pons terms currently in effect. This is recomputed on every read and marked stale whenever any of its inputs change, including the Pons stack address, the adapter's launch namespace, the market salt, the economics digest, the fee policy snapshot, the launch fee, or the metadata. It is never shown as the token's address, never in share images, and never treated as fixed. At birth, the actual address is read back from the Pons record.

Birth

One router forwards every birth to the market's own venue, and the readback has to agree before the token is adopted.

Birth goes through a single KnokqLaunchRouter. The router accepts a birth only from a market the KNOKQ factory created, and forwards it to the venue that market bound at arm. For a market on Pons, that venue is PonsV2Adapter, the Pons launcher of record. The adapter forces the terms KNOKQ requires: the market is the creator fee recipient, creator tax is zero, and Pons buyback is off.

The market then verifies the launch by reading the venue's record back and comparing it against the armed terms, before it adopts the launched token as its own. If the venue configuration drifted between arm and birth, or a pause is active, the venue call is blocked and the reason is recorded, without touching the latch.

A launch that does not verify on the first try is not stuck. verifyBirth() can promote it later if the mismatch resolves. If it never does, declareBirthUnverifiable() can be called by anyone after a seven-day public delay that re-checks first, returning the creator's preload. declareBirthUnexecutable() covers a trigger that latched but never launched. It first attempts the launch itself with a fixed gas budget, and only makes the market terminal if that attempt reverts.

Launch venues

Pons v2 is the default launch venue. KNOKQ's own native venue is deployed and paused, and every market keeps the venue it armed on.

KNOKQ reaches a launch venue through one interface, and the factory keeps a registry of venues. A market binds the factory's default venue when it is armed and keeps it for life, the same way it keeps its trigger policy. A change of default applies only to markets armed afterwards, so markets already on Pons stay on Pons.

The owner registers venues and selects the default. Selecting a new default switches public arming off until the owner turns it back on. Each venue has its own pause, and nothing falls back from one venue to another on its own. A registered venue is trusted as much as the market implementation.

The native venue exists so KNOKQ does not depend on a single third-party launchpad. On it, curve and pool fees are owed only to the market and anyone can collect them, so post-graduation revenue does not wait on an operator. It went through the same internal review as the core, and it stays paused and out of use unless the owner selects it.

Trading

Before graduation a Pons market trades on its bonding curve, and the quoted cost is exact.

After birth, a market on the default Pons venue is live and tradable on the Pons v2 bonding curve. The trade cost shown before signing is what the curve will actually charge, to the wei, including partial fills and refunds.

After the token graduates into a Uniswap v4 pool, trades route through that pool instead, and are quoted separately from the curve.

Graduation

On Pons, graduation is not guaranteed to finish in the same transaction as the trade that fills the curve, and anyone can push it forward.

On Pons, a buy that fills the curve calls the Pons factory to graduate, which drains the curve and sets its phase to Swept. Creating the graduated pool is a separate, permissionless call. On mainnet, that second call lands in the same transaction only when a third-party router wraps both together, which happened in 115 of a recent sample of 253 graduations. The rest resolved between 1 and 147 blocks later.

A KNOKQ cycle buy that fills the curve creates the graduated pool in the same transaction it runs in. Outside of that path, GRADUATING is a short-lived, normal state, and anyone can call the function that pushes a stalled graduation forward. The native venue graduates in the same transaction as the buy that reaches its boundary.

Revenue

Revenue that reaches the market splits 60/30/10, and Pons keeps control of where the fee route points.

Creator-side revenue that reaches the market contract splits 60% to the active cycle, 30% to the creator, and 10% to the protocol. This applies only to revenue that actually reached the market, and rounding dust goes to the cycle.

A market that can never run a cycle, because it was declared terminal or expired without a birth, books arriving value 75% to the creator and 25% to the protocol instead, and moves any loaded cycle balance to those two claims.

Under the current Pons fee configuration, the market receives 0.70% of trading volume, of which 0.42% loads into cycles. Pons can change fee terms for future launches, but each market is bound to the terms it launched with. KNOKQ does not add a hidden trading tax on top of this. Pons's own base fee still applies and is shown alongside it.

Loaded, staged, and pending venue sweep

These are three separate balances. KNOKQ never sums them into one number.

A market tracks revenue in three states, and a cycle can only ever spend what was LOADED when it triggered.

A running cycle can never spend more than the balance frozen at the moment it triggered. Revenue that arrives after a trigger is STAGED for the next cycle and never appended to the one already running.

Recurring KNOKQ cycles

A cycle resolves and rearms in the same transaction, and every resolved cycle stays on chain.

When a cycle's barrier is crossed it triggers, executes in permissionless tranches sized by a price-impact ceiling and capped at a quarter of the frozen commitment per tranche, and rearms once it finishes. Every resolved cycle is appended to an on-chain history rather than overwritten, so a market's full burn record does not depend on an indexer.

A cycle can trigger with nothing loaded. That state is recorded as TRIGGERED_ZERO_LOAD: no buyback is fabricated, and later revenue funds that same cycle until it can actually execute. A cycle becomes executable only once at least 1e12 wei, about a millionth of an ETH, is committed, because no venue can fill a smaller amount.

If a tranche has no executable route, it waits rather than reverting, leaves the committed balance untouched, and any later caller can retry it. If a latched cycle makes no progress for 14 days, counted from its latch, from when it became executable, or from its last spending tranche, anyone can release the unspent commitment back to the loaded balance. On a venue that reports a rescued launch, that release opens seven days after the latch. The cycle then resolves with what it actually did, and the record shows the released amount apart from the spent amount.

Buyback and burn

Each tranche reads token supply before and after a burn and requires the drop to match exactly.

A cycle tranche buys the token, then burns what it bought. Each burn reads totalSupply(), burns the amount, reads totalSupply() again, and requires the fall to equal what was burned.

Oracle policy

Stale, paused, or invalid oracle state cannot trigger, and the production policy adds session and freshness rules on top.

A stale round, a paused oracle, a non-positive answer, an invalid multiplier, or an inactive asset all refuse with a named reason before any policy is even consulted. These checks belong to the trigger engine itself and cannot be relaxed by a policy.

The production policy, TriggerPolicyV1, adds three more conditions. The feed must be production-enabled with its own measured freshness ceiling, its maxAge. The observation and the feed round it came from must both fall inside the same published US regular trading session. One qualifying round is enough, with no second-round confirmation. Pre-market, post-market, and overnight sessions do not count.

The session calendar lives on chain. Trading days, holidays, and early closes are published ahead of time from the NYSE schedule, never for today or a past day, and any day that is not published fails closed.

Supported Stock Tokens

Seven Stock Tokens are seeded in the production registry and can back a KNOKQ market.

KNOKQ reads Robinhood Stock Token prices on chain through Chainlink feeds. Of the roughly 195 Stock Tokens Robinhood lists, 35 have a published feed on Robinhood Chain, and of those, seven meet the measured freshness requirement to be production-enabled. Those seven are the only assets in the production registry.

Execution protection

A cycle tranche prices itself against a reference sampled before the spend, so a same-block front-run cannot widen its own bound.

Every cycle carries an execution reference price, sampled when the trigger latches and re-anchored when the venue's phase changes. The re-anchor is rate limited against the old reference, and a zero price never replaces a reference. A tranche checks the live price against that reference plus an impact ceiling before it spends, and checks the realized price against the same ceiling after. A tranche cannot spend in the same block its reference was sampled in.

Measured on a fork, this bound holds at every tested attack size: 5%, 10%, 20%, 40%, and 80% front-runs all extract zero from the tranche, with the attacker's own return negative in every case. A same-transaction sandwich spends zero on both venues.

MEV limitations

The execution protection bounds manipulation at the moment a tranche spends. It does not stop an attacker from positioning ahead of a trigger.

Pre-trigger manipulation is not solved and is not claimed to be. A market's barrier is public, so the arrival of a buyback is predictable, and an attacker who positions before the trigger latches and holds through it is measurably profitable, at 272 to 4085 basis points of return on Pons, in both the curve phase and the graduated pool phase.

Several stricter reference designs were built and measured against the real venue specifically to close this. None removed a single profitable case. Two of them stranded 75 to 79 percent of an honest tranche's own commitment, and one made pool extraction 5.5 times worse. In the large cases the profit comes from anticipating a publicly announced buyer, which no reference rule removes.

Proof and verification

Burns, launches, and revenue are each checked against an independent read. Indexed history is confirmed to a depth, never labeled final.

A burn is proven by reading totalSupply() before and after and requiring the exact fall. A birth is proven by reading the venue's launch record back and comparing it to the armed terms. Revenue attribution is proven by measuring the balance delta around each claim rather than trusting a claimed amount.

The indexer follows the chain head and only marks a row confirmed once it sits behind a confirmation depth. If a reorg pulls a row back inside that window, it is unconfirmed again rather than staying marked as settled.

Permissionless actions

Every state-advancing call in KNOKQ can be made by any wallet, not only by a creator or a keeper.

KNOKQ runs a keeper that submits these calls promptly. It is automation with no special permission, and every call it makes is one any wallet could make. If it stops running, every one of these actions can still be taken by anyone.

What creators can and cannot change

The barrier, direction, expiry, and token identity are fixed at arm. A small set of recovery exits exist for when a launch genuinely cannot proceed.

• Cannot launch the market early. Only the trigger engine can set the birth latch.
• Cannot change the barrier, direction, expiry, or token identity after arming.
• Cannot move an armed market onto a newer trigger policy version or another venue. A new policy or default venue applies only to markets armed after it is selected.
• Cannot withdraw committed cycle capital while a market is active.

A creator does receive 30% of revenue collected once the market is alive, and can use three permissionless recovery exits when a market genuinely cannot proceed: an untriggered expiry, a launch that never verifies, or a trigger that latched but never launched. Each exit is behind a public delay that re-checks the condition first, so a market that could still succeed cannot be declared terminal early.

Known external dependencies

KNOKQ depends on Robinhood Chain, Chainlink, Pons v2, Uniswap v4, and RPC providers behaving as documented.

Robinhood Chain

Sets block timestamps and orders transactions first-come-first-served. Stock Tokens are beacon proxies, and Robinhood can upgrade every Stock Token's logic in a single transaction through its own upgrader role.

Chainlink

Publishes the price feeds KNOKQ reads. Which Stock Tokens have a feed at all, and how fresh each feed's rounds are, is decided by Chainlink's own directory and update cadence, not by KNOKQ.

Pons v2

The default launch venue. Provides the launch factory, bonding curve, fee accounting, and graduation into Uniswap v4 that Pons-backed markets run on. KNOKQ pins and checks the deployed contract code it depends on, so a stack replacement is detected rather than silently trusted.

Uniswap v4

Hosts the graduated trading pool and is where post-graduation cycle buybacks execute. There is no exact-output quoter deployed alongside the Pons stack, so tranche sizing after graduation is done by on-chain simulation.

RPC providers

The interface, the indexer, and the keeper read the chain through RPC endpoints. The public endpoint keeps only a short window of state and rate-limits hard, so a slow or failing provider shows up as unavailable data or a lagging index.

Network

KNOKQ runs on Robinhood Chain, chain id 4663.

KNOKQ runs on Robinhood Chain mainnet, chain id 4663. The public RPC endpoint keeps only about 10 to 17 minutes of historical state, so it is not suitable for deep historical queries. Production reads use an archive-capable provider.

Contracts

KNOKQ is deployed on Robinhood Chain mainnet from block 71874461, built from commit 17ba693. Every KNOKQ contract below has its source verified on Sourcify as an exact match. The external contracts KNOKQ depends on are pinned by codehash.

KNOKQ

The factory arms markets and registers each one with the launch router against the default venue. The router is the only caller of any venue's launch, and only for a market the factory created. The Pons adapter is the default venue. The native venue, with its hook and curve implementation, is registered and paused, and no market is armed on it.

External

Read API

Indexed reads. Amounts cross the wire as decimal strings with their decimals, never as JSON numbers, and no endpoint can mark on-chain state as complete.