Proof, KNOKQ

What a receipt walks through

One canonical end-to-end run, read in causal order: what was armed, what the trigger refused, what latched, what was born, and what the supply did afterwards.

Nothing to index yet

Production contracts are not deployed to Robinhood Chain yet, so there are no markets to index.

Nothing is shown in place of this data. KNOKQ does not display sample markets, prices or totals.

No canonical run is indexed yet, so no link below carries a status. This is the shape a receipt will take, in causal order.

Arm, with the terms written and frozen.
A pre-barrier state that was rejected, showing the trigger refusing to latch early.
The first valid observation that met the barrier.
Birth on the Pons v2 venue.
An independent readback that the token exists.
Trade and the revenue that reached the market contract.
The cycle armed at the next barrier.
Execution, with the quote spent acquiring the token.
The burn.
totalSupply read back, down by exactly the amount acquired.

No early launch

Claim ledger C-03

Claim: No one can launch a market early through KNOKQ.
Source: Fork tests G4 (trigger state machine) and G5 (birth end to end) against Robinhood Chain state.
On-chain state: KnokqMarket births only from a latched trigger, and only the trigger engine can set the latch. The router accepts a launch only from a registered market.
Current observation: Production deployment pending
Evidence so far: On the fork, every birth attempt before a valid latch reverts, and a latched trigger survives a venue failure, a guardian pause, a price reversal and expiry.
Verification method: forge test --match-path test/fork/G4TriggerStateMachine.t.sol and G5BirthEndToEnd.t.sol in packages/contracts.
Limitation: A guardian pause can delay a launch. It can never cause one.

Bad oracle state refuses

Claim ledger C-11

Claim: Stale, paused or invalid oracle state cannot trigger a barrier.
Source: Fork tests G3 (oracle normalization) and G4.
On-chain state: The trigger engine's core checks run before any policy: asset binding, positive answer, oracle not paused, valid multiplier, minimum arm age, not expired, economic barrier met. A policy can add rules, never remove these.
Current observation: Production deployment pending
Evidence so far: On the fork, each failure refuses with a named reason and leaves the market untouched.
Verification method: forge test --match-path test/fork/G3OracleNormalization.t.sol.
Limitation: The freshness ceiling belongs to the trigger policy and is still being settled (D-007, D-008). No sequencer-health check exists or is substituted.

Splits cannot trigger

Claim ledger C-10

Claim: A stock split or dividend cannot trigger a barrier.
Source: Unit and fuzz tests in EconomicBarrier.t.sol, and the fork with real multiplier updates.
On-chain state: The barrier is converted once at arm, using the Stock Token multiplier snapshotted then, and compared in economic terms from then on.
Current observation: Production deployment pending
Evidence so far: Real multiplier updates on the fork move the displayed share barrier and never the trigger decision.
Verification method: forge test --match-path test/unit/EconomicBarrier.t.sol.
Limitation: The displayed share barrier restates after each corporate action, and drifts down slightly with dividends.

Revenue split and loading

Claim ledger C-05, C-20

Claim: Revenue that reaches the market splits 60% to the cycle, 30% to the creator and 10% to the protocol, and only LOADED and STAGED value counts.
Source: Fork test G2 (fee routing) and the invariant campaign.
On-chain state: KnokqMarket measures the balance change around each claim rather than trusting a claimed amount, then splits it. Rounding dust goes to the cycle.
Current observation: Production deployment pending
Evidence so far: On the fork the split is exact, and PENDING_VENUE_SWEEP is never summed into an executable total across the whole invariant run.
Verification method: forge test --match-path test/fork/G2FeeRouting.t.sol and pnpm invariants.
Limitation: It applies only to revenue that actually reached the market. It is never true that every trade loads the next barrier.

Frozen cycle commitment

Claim ledger C-21

Claim: A cycle can never spend more than the balance frozen when it triggered.
Source: Fork test G7 (cycle engine) and the invariant campaign.
On-chain state: The commitment is frozen at trigger. Revenue that arrives afterwards is STAGED for the next cycle and is out of reach of the running one.
Current observation: Production deployment pending
Evidence so far: No execution path in the campaign spends past the frozen amount.
Verification method: forge test --match-path test/fork/G7CycleEngine.t.sol and pnpm invariants.
Limitation: A cycle that triggers with nothing loaded records TRIGGERED_ZERO_LOAD and buys nothing until revenue arrives.

Burns are read back

Claim ledger C-13

Claim: Tokens a cycle buys back are burned, and the burn is read back.
Source: Fork tests G3.6 (burn lifecycle) and G7.
On-chain state: Each tranche reads totalSupply(), burns, reads it again and reverts unless the fall equals the amount burned.
Current observation: Production deployment pending
Evidence so far: On the fork the supply falls by exactly the amount acquired in every executed tranche.
Verification method: For any burn transaction, read totalSupply() on the token at the block before and the block of the burn.
Limitation: Pons displays built on launchSupply do not show burns. Read totalSupply().

Quotes match the curve

Claim ledger C-26

Claim: The trade cost shown before signing is what the Pons curve will charge.
Source: Fork test G6 (venue lifecycle).
On-chain state: Quotes come from PonsV2Adapter, the same contract the market and the keeper quote against, which replicates the curve including fee legs, snipe tax and partial fills.
Current observation: Production deployment pending
Evidence so far: On the fork, quoted and executed amounts agree to the wei, including partial fills and refunds at graduation.
Verification method: forge test --match-path test/fork/G6VenueLifecycle.t.sol.
Limitation: It covers the curve phase. The graduated Uniswap v4 pool route is quoted separately.

Creator recovery exits

Claim ledger C-28

Claim: Creator funds can be recovered when a market cannot proceed.
Source: Security tests after the Phase B fixes (D-031, D-034, D-035).
On-chain state: Three permissionless exits: an untriggered expiry, a launch that never verifies, and a trigger that latched but never launched. Each re-checks its condition after a public delay.
Current observation: Production deployment pending
Evidence so far: In the security tests each exit opens when its condition holds, and a declaration cannot win a race against a launch that would still verify.
Verification method: forge test --match-path test/security/BirthRecovery.t.sol.
Limitation: Recovery takes a public delay. It is not instant.

Arming gate

Claim ledger C-23

Claim: Mainnet arming stays closed until a production trigger policy is approved.
Source: Unit tests in KnokqProductionGate.t.sol and the deployment script's postconditions.
On-chain state: Enforced in the factory constructor, in setArmingEnabled, on every arm, and in the deploy script. The test policy reports productionApproved() false with no setter.
Current observation: Production deployment pending
Evidence so far: Every path that would open arming without an approved policy reverts.
Verification method: Once deployed, call armingEnabled() on the factory. Today, forge test --match-path test/unit/KnokqProductionGate.t.sol.
Limitation: Opening arming is a separate human decision after deployment, never part of it.

What KNOKQ does not claim

Each line is an entry in the claim ledger that is false or limited, kept in the ledger's own words.

That a token's future address is fixed before birth: Only a predicted address with recorded dependencies, marked stale when any of them changes, and never in the primary claim.
That every trade loads the next barrier: Only LOADED and STAGED count. PENDING_VENUE_SWEEP never does, and the three are never summed into one number.
That KNOKQ is MEV-proof or sandwich-proof: Atomic manipulation around an execution is bounded or refused. Positioning before a public trigger stays profitable: measured at 272 to 4085 bps.
That post-graduation revenue is reliable: Usually minutes, with observed stalls of about 8.5 days on a 1.43 ETH balance. It is eventual and operator-dependent.
That every Stock Token is supported: Only 35 of 195 Robinhood Stock Tokens have a Chainlink feed on Robinhood Chain today.
That any cycle has executed on mainnet: Production contracts are not deployed yet, so no canonical mainnet run exists.

What a receipt walks through

One canonical end-to-end run, read in causal order: what was armed, what the trigger refused, what latched, what was born, and what the supply did afterwards.

Nothing to index yet

Production contracts are not deployed to Robinhood Chain yet, so there are no markets to index.

Nothing is shown in place of this data. KNOKQ does not display sample markets, prices or totals.

No canonical run is indexed yet, so no link below carries a status. This is the shape a receipt will take, in causal order.

Arm, with the terms written and frozen.
A pre-barrier state that was rejected, showing the trigger refusing to latch early.
The first valid observation that met the barrier.
Birth on the Pons v2 venue.
An independent readback that the token exists.
Trade and the revenue that reached the market contract.
The cycle armed at the next barrier.
Execution, with the quote spent acquiring the token.
The burn.
totalSupply read back, down by exactly the amount acquired.

No early launch

Claim ledger C-03

Claim: No one can launch a market early through KNOKQ.
Source: Fork tests G4 (trigger state machine) and G5 (birth end to end) against Robinhood Chain state.
On-chain state: KnokqMarket births only from a latched trigger, and only the trigger engine can set the latch. The router accepts a launch only from a registered market.
Current observation: Production deployment pending
Evidence so far: On the fork, every birth attempt before a valid latch reverts, and a latched trigger survives a venue failure, a guardian pause, a price reversal and expiry.
Verification method: forge test --match-path test/fork/G4TriggerStateMachine.t.sol and G5BirthEndToEnd.t.sol in packages/contracts.
Limitation: A guardian pause can delay a launch. It can never cause one.

Bad oracle state refuses

Claim ledger C-11

Claim: Stale, paused or invalid oracle state cannot trigger a barrier.
Source: Fork tests G3 (oracle normalization) and G4.
On-chain state: The trigger engine's core checks run before any policy: asset binding, positive answer, oracle not paused, valid multiplier, minimum arm age, not expired, economic barrier met. A policy can add rules, never remove these.
Current observation: Production deployment pending
Evidence so far: On the fork, each failure refuses with a named reason and leaves the market untouched.
Verification method: forge test --match-path test/fork/G3OracleNormalization.t.sol.
Limitation: The freshness ceiling belongs to the trigger policy and is still being settled (D-007, D-008). No sequencer-health check exists or is substituted.

Splits cannot trigger

Claim ledger C-10

Claim: A stock split or dividend cannot trigger a barrier.
Source: Unit and fuzz tests in EconomicBarrier.t.sol, and the fork with real multiplier updates.
On-chain state: The barrier is converted once at arm, using the Stock Token multiplier snapshotted then, and compared in economic terms from then on.
Current observation: Production deployment pending
Evidence so far: Real multiplier updates on the fork move the displayed share barrier and never the trigger decision.
Verification method: forge test --match-path test/unit/EconomicBarrier.t.sol.
Limitation: The displayed share barrier restates after each corporate action, and drifts down slightly with dividends.

Revenue split and loading

Claim ledger C-05, C-20

Claim: Revenue that reaches the market splits 60% to the cycle, 30% to the creator and 10% to the protocol, and only LOADED and STAGED value counts.
Source: Fork test G2 (fee routing) and the invariant campaign.
On-chain state: KnokqMarket measures the balance change around each claim rather than trusting a claimed amount, then splits it. Rounding dust goes to the cycle.
Current observation: Production deployment pending
Evidence so far: On the fork the split is exact, and PENDING_VENUE_SWEEP is never summed into an executable total across the whole invariant run.
Verification method: forge test --match-path test/fork/G2FeeRouting.t.sol and pnpm invariants.
Limitation: It applies only to revenue that actually reached the market. It is never true that every trade loads the next barrier.

Frozen cycle commitment

Claim ledger C-21

Claim: A cycle can never spend more than the balance frozen when it triggered.
Source: Fork test G7 (cycle engine) and the invariant campaign.
On-chain state: The commitment is frozen at trigger. Revenue that arrives afterwards is STAGED for the next cycle and is out of reach of the running one.
Current observation: Production deployment pending
Evidence so far: No execution path in the campaign spends past the frozen amount.
Verification method: forge test --match-path test/fork/G7CycleEngine.t.sol and pnpm invariants.
Limitation: A cycle that triggers with nothing loaded records TRIGGERED_ZERO_LOAD and buys nothing until revenue arrives.

Burns are read back

Claim ledger C-13

Claim: Tokens a cycle buys back are burned, and the burn is read back.
Source: Fork tests G3.6 (burn lifecycle) and G7.
On-chain state: Each tranche reads totalSupply(), burns, reads it again and reverts unless the fall equals the amount burned.
Current observation: Production deployment pending
Evidence so far: On the fork the supply falls by exactly the amount acquired in every executed tranche.
Verification method: For any burn transaction, read totalSupply() on the token at the block before and the block of the burn.
Limitation: Pons displays built on launchSupply do not show burns. Read totalSupply().

Quotes match the curve

Claim ledger C-26

Claim: The trade cost shown before signing is what the Pons curve will charge.
Source: Fork test G6 (venue lifecycle).
On-chain state: Quotes come from PonsV2Adapter, the same contract the market and the keeper quote against, which replicates the curve including fee legs, snipe tax and partial fills.
Current observation: Production deployment pending
Evidence so far: On the fork, quoted and executed amounts agree to the wei, including partial fills and refunds at graduation.
Verification method: forge test --match-path test/fork/G6VenueLifecycle.t.sol.
Limitation: It covers the curve phase. The graduated Uniswap v4 pool route is quoted separately.

Creator recovery exits

Claim ledger C-28

Claim: Creator funds can be recovered when a market cannot proceed.
Source: Security tests after the Phase B fixes (D-031, D-034, D-035).
On-chain state: Three permissionless exits: an untriggered expiry, a launch that never verifies, and a trigger that latched but never launched. Each re-checks its condition after a public delay.
Current observation: Production deployment pending
Evidence so far: In the security tests each exit opens when its condition holds, and a declaration cannot win a race against a launch that would still verify.
Verification method: forge test --match-path test/security/BirthRecovery.t.sol.
Limitation: Recovery takes a public delay. It is not instant.

Arming gate

Claim ledger C-23

Claim: Mainnet arming stays closed until a production trigger policy is approved.
Source: Unit tests in KnokqProductionGate.t.sol and the deployment script's postconditions.
On-chain state: Enforced in the factory constructor, in setArmingEnabled, on every arm, and in the deploy script. The test policy reports productionApproved() false with no setter.
Current observation: Production deployment pending
Evidence so far: Every path that would open arming without an approved policy reverts.
Verification method: Once deployed, call armingEnabled() on the factory. Today, forge test --match-path test/unit/KnokqProductionGate.t.sol.
Limitation: Opening arming is a separate human decision after deployment, never part of it.

What KNOKQ does not claim

Each line is an entry in the claim ledger that is false or limited, kept in the ledger's own words.

That a token's future address is fixed before birth: Only a predicted address with recorded dependencies, marked stale when any of them changes, and never in the primary claim.
That every trade loads the next barrier: Only LOADED and STAGED count. PENDING_VENUE_SWEEP never does, and the three are never summed into one number.
That KNOKQ is MEV-proof or sandwich-proof: Atomic manipulation around an execution is bounded or refused. Positioning before a public trigger stays profitable: measured at 272 to 4085 bps.
That post-graduation revenue is reliable: Usually minutes, with observed stalls of about 8.5 days on a 1.43 ETH balance. It is eventual and operator-dependent.
That every Stock Token is supported: Only 35 of 195 Robinhood Stock Tokens have a Chainlink feed on Robinhood Chain today.
That any cycle has executed on mainnet: Production contracts are not deployed yet, so no canonical mainnet run exists.