Smart contract risk
KNOKQ's contracts are new code. They are internally reviewed and extensively tested, and an independent third-party audit is pending.
The internal review ran in five passes, each by a reviewer who had not written the code under review, and closed on commit 17ba693 with no Critical or High finding open. At that commit, 438 Foundry tests pass across 56 suites, including tests against the live Pons stack on a mainnet fork, invariant campaigns, and a regression test for every fixed finding.
Testing and internal review find real issues. They do not prove that none are left, and they do not replace an independent audit. You can lose everything you commit to a market.
Every market runs as a clone of the market implementation it was armed with and is never upgraded. A new implementation serves only markets armed after it, so a bug found later is not patched in markets that already exist.
Oracle risk
Triggers depend on Chainlink feeds, a published session calendar, and a freshness limit per feed. When any of them fails, triggers fail closed.
Every trigger reads the Stock Token's Chainlink feed. Under TriggerPolicyV1 a trigger latches only on a round published during the US regular trading session, on a day the on-chain session calendar records as a trading day, and no older than that feed's maxAge, which runs from 2,400 to 3,600 seconds across the seven supported feeds. One qualifying round is enough. Pre-market, post-market, and overnight sessions do not count.
Feeds can go stale. Chainlink sets each feed's update cadence, and a feed can slow down or stop. When no fresh in-session round exists, nothing latches, even if the stock has crossed the barrier in the market. A paused oracle, a non-positive answer, or an invalid multiplier refuse the same way. The result is a missed trigger rather than a false one, and a market can miss a move it would otherwise have caught.
The session calendar is published ahead of time from the NYSE schedule and currently covers days through the end of 2028. A day that is not published fails closed, and an unscheduled market closure is never added after the fact. Robinhood Chain has no on-chain sequencer uptime feed, and none is substituted.
Trigger coverage is intentionally limited
Only seven Stock Token feeds meet the freshness bar required to trigger a market.
Of roughly 195 Robinhood Stock Tokens, 35 have a published Chainlink feed on Robinhood Chain, and of those, seven meet the measured freshness requirement to be production-enabled: CLSK, CRCL, CRWV, DELL, SNDK, USAR, and USO. A Stock Token without a feed, or with a feed that does not meet the freshness bar, cannot back a KNOKQ market.
Launch venue risk
Pons v2, the default launch venue, is a third party. KNOKQ checks what Pons does and cannot control it.
Markets armed on the default venue launch and trade on Pons v2 through KNOKQ's Pons adapter. Pons decides its own fee terms, launch gate, and graduation mechanics. It can change fee terms for future launches, and it can close the public launch gate, in which case Pons would need to admit KNOKQ's adapter by name before any new launch goes through.
KNOKQ snapshots the Pons configuration at arm and compares it again at birth. Drift blocks the launch and records what moved, and the launched token is read back before a market adopts it. That catches a change. It does not prevent one.
When KNOKQ's review recorded it, Pons's own documentation described v2 as unaudited, with audits in progress. Check Pons's current documentation for its status. KNOKQ's dependency on Pons carries whatever risk that implies.
KNOKQ's own native venue is deployed but paused, and it is not the default. A market keeps the venue it armed on for life, and nothing falls back from one venue to another on its own, so a market on Pons stays on Pons whatever happens to Pons.
Post-graduation revenue depends on the Pons operator
After graduation on Pons, sweeping fees to the market usually needs an external operator, and that operator can stall.
Before graduation, the market can sweep its own trading fees. After graduation on Pons, most fee sweeps require the Pons operator, because an ordinary buy on the graduated pool accrues fees in a form the market cannot convert on its own. Revenue that is stuck this way sits as PENDING VENUE SWEEP and is never counted as spendable.
Pons can redirect a market's fee route
Pons's owner can propose a new fee recipient for a market, and anyone can execute it after a three-day notice.
Pons has a public takeover path for a token's fee recipient. Its owner can propose a change, and after a three-day public notice, anyone can execute it. A voluntary transfer during that notice period does not cancel a pending takeover.
KNOKQ detects both a pending and a completed redirection and surfaces it. It cannot prevent one. If a market's fee route is redirected, future cycle funding from that market can stop.
Market and liquidity risk
A new token trades on a bonding curve and then a thin pool. Its price can move a long way on small trades, and it can go to zero.
A token launched through KNOKQ has no value guaranteed by anyone. Before graduation, its price is set by a bonding curve that moves with each trade. After graduation, it trades against whatever liquidity the pool holds, which for a new token can be thin, so a small trade can move the price a long way and a large one may not fill near the price you expect.
Graduation into a Uniswap v4 pool is not guaranteed to happen in the same transaction as the trade that finishes the curve. In a recent sample of 253 Pons graduations, 115 completed in the same transaction and the rest landed up to 147 blocks later. Trading is restricted while a graduation is in progress.
A cycle buyback spends only the capital that was loaded when its barrier triggered, in tranches capped by price impact and by size. It is not a price floor and does not support the price between cycles.
Public barriers make future actions predictable
A market's barrier, and the buyback it will trigger, are visible on chain before either happens.
A market's barrier, direction, and distance to it are all readable on chain. So is the size of the balance a cycle will spend when it triggers. This transparency is intentional, and it also means anyone can plan around a coming trigger before it happens, not only after.
KNOKQ is not MEV-proof
Execution protection refuses an atomic sandwich at the moment a tranche spends. It is not a general guarantee against MEV.
A cycle's execution reference is sampled before the tranche spends, and a tranche cannot spend in the same block its reference was set. A front-run, tranche, and back-run in one transaction therefore spends zero. Measured on a fork, this holds the atomic sandwich to zero extraction at every tested attack size, with the attacker's own return negative.
Pre-trigger anticipation remains possible
An attacker who positions ahead of a public, predictable trigger can profit from the barrier being visible in advance.
Because a barrier and its distance are public, the arrival of a buyback is predictable. An attacker who buys ahead of a trigger and holds through it can profit, and KNOKQ's tranche then buys fewer tokens than it would have. Several stricter designs built specifically to close this failed to remove the profitability without also degrading honest execution.
Cycle capital can wait, and sometimes cannot move
Committed cycle capital waits when no route can fill it, and loaded capital in a market whose oracle dies has no way out.
A cycle commits the balance loaded when it triggered and spends it in tranches. A tranche with no executable route, or with a live price outside its execution envelope, waits and spends nothing. After a graduation that moved the price several times over in one block, the first pool tranches wait until refreshes from later blocks catch the reference up. While capital waits, it is not buying back or burning anything.
A latched cycle that makes no progress for 14 days, counted from its latch, from when it became executable, or from its last spending tranche, can be released by anyone. On a venue that reports a rescued launch, the release opens seven days after the latch. The unspent commitment returns to the loaded balance and the cycle resolves with what it actually did.
Owner and guardian powers
The owner and guardian can change what new markets get and can delay existing ones. The registry owner can stop existing markets from triggering. None of them can change an armed market's terms or move its funds.
The factory owner registers launch venues, selects the default venue and the trigger policy for new markets, sets protocol parameters inside fixed ranges, sets the protocol treasury, names canary armers, and switches public arming. None of that changes a market already armed. Each market keeps its terms, its venue, its trigger policy version, and its execution envelope for life. The only live read is the treasury address, which receives the protocol's own 10% share when it is claimed.
The guardian, like the owner, can pause a venue or all venue calls. A pause can delay a launch or a cycle. It cannot clear a latched trigger, change a barrier, or move funds.
The registry owner can rebind or deactivate a Stock Token's entry, disable its feed for production, or change that feed's maxAge within the 3,600-second ceiling, and each of these applies to markets already armed. A rebinding, a deactivation, or a disabled feed stops those markets from triggering, which leaves their loaded cycle capital waiting as described above. A raised maxAge lets an older round from the same session count, never one older than an hour. None of these can get a trigger past the core oracle checks, and every change is visible on chain.
The owner can also name canary armers, who can arm while public arming is closed. That is how the first mainnet market was armed, before public arming opened.
Third-party dependencies
Robinhood Chain, Chainlink, Pons, Uniswap v4, and RPC providers can each change or fail, and KNOKQ controls none of them.
Robinhood Chain sets block timestamps and orders transactions. Stock Tokens are upgradeable beacon proxies, and Robinhood can change every Stock Token's logic in a single transaction, so KNOKQ reads pricing and pause state from code it does not control. Chainlink decides which Stock Tokens get a feed and how often each one updates. Pons decides its own fee terms, launch gate, and graduation mechanics. Uniswap v4 hosts every graduated pool.
This interface, the indexer, and the keeper read the chain through RPC providers. The public Robinhood Chain endpoint keeps only about 10 to 17 minutes of state and rate-limits hard. If a provider is slow or down, pages show data as unavailable, the index falls behind, and the keeper can fall behind too. Any wallet can still send the same transactions.
KNOKQ pins and checks the contract code it depends on where it can, so a stack replacement is detected rather than silently trusted. Detecting a change does not give KNOKQ any control over it.
Indexed data can lag and is not finality
What the app displays comes from an indexer that follows the chain head and can revise recent state.
Most of what the app shows is indexed state, read from a database the indexer fills as it follows the chain. The indexer can lag the chain head. It marks a row confirmed only once it clears a confirmation depth, and unconfirms it again if a reorg pulls it back inside that window.
Wallet and transaction risk
Ordinary wallet and transaction risk applies, and Robinhood Chain's sequencing adds its own considerations.
Using KNOKQ means signing and sending transactions from a wallet you control, with the usual risks of approving the wrong amount, signing a malicious transaction, or losing key custody. None of that is specific to KNOKQ.
Robinhood Chain orders transactions first-come-first-served with no priority fee auction, which turns MEV around public events into a latency race rather than removing it. The sequencer also screens out transactions touching sanctioned addresses.
Public arming is switched on chain
Whether anyone can arm a market is decided by the factory, and the Status page reads it live.
Every deployment starts with public arming off. The owner opens it with a separate transaction, never as part of a deployment, and the factory refuses to open it unless the selected trigger policy reports itself production-approved. Until it opens, only a designated canary account can arm. Once it opens, any wallet that meets the factory's rules can.
Status reads the factory and shows whether public arming is open right now. Proof shows how far the first mainnet market has got. Where a figure on this page has no mainnet run behind it yet, it comes from fork tests.