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 through Pons v2. 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. A keeper is a convenience, not an authority.

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, the cycle step, the expiry window, the quote asset, a live oracle read, the barrier distance, and the Pons 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.

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, not whatever multiplier is current. This is 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 router 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 through Pons

A single router launches every market, and the readback has to agree before the token is adopted.

A single KnokqLaunchRouter is the Pons caller for every KNOKQ market. On the Pons record, the router is the deployer of record, but the market itself remains the creator fee recipient, with creator tax set to zero and buyback off.

Birth calls the router, then verifies the launch by reading the Pons record back and comparing it against the armed terms, before the market adopts the launched token as its own. If Pons configuration drifted between arm and birth, or a guardian 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 the case where a trigger latched but the launch never ran at all, on the same seven-day pattern.

Trading

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

After birth, the token 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

Graduation is not guaranteed to happen in the same transaction as the trade that finishes the curve, and anyone can push it forward.

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 finishes 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.

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 to revenue that actually reached the market; rounding dust goes to the cycle.

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, but 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, not 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.

If a tranche has no executable venue route, it waits rather than reverting, leaving the committed balance untouched, and any later caller can retry it. A venue that ends up permanently unusable releases its frozen commitment back to the active balance after a public delay, so capital is never spent and never stranded indefinitely.

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 current 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 current production policy, TriggerPolicyV1, adds three more conditions. The feed must be production-enabled with its own measured freshness ceiling. 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; there is no second-round confirmation requirement in v1.

Supported Stock Tokens

Seven Stock Tokens are production-enabled to trigger a KNOKQ market today.

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 currently meet the measured freshness requirement to be production-enabled for triggering a market.

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. 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.

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 across both the curve and the pool venue.

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. The profit in the large cases is not the reference being poisoned; it is anticipation of 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 Pons 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.

A keeper service exists to submit these calls promptly, but it holds no special permission. If it stops running, every one of these actions can still be taken by any wallet.

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. A new policy 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, and Uniswap v4 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

Provides the launch factory, bonding curve, fee accounting, and graduation into Uniswap v4 that KNOKQ builds 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.

Network

KNOKQ runs on Robinhood Chain, chain id 4663.

KNOKQ is built for Robinhood Chain, chain id 4663. The public RPC endpoint keeps only a short window of historical state, so it is not suitable for deep historical queries; production reads should use an archive-capable provider.

Contracts

No KNOKQ contract is deployed to Robinhood Chain mainnet yet. The external contracts KNOKQ depends on are already live.

KNOKQ

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.