How it works.

There is no seller on the other side of a trade here. There is a pile, and rules about what it costs to take things out of it.

A pool is a pile of two things

People deposit shares of NVIDIA and dollars into one contract. When you buy, you are not matched against another trader: you take shares out of the pile and put dollars in. That pile is the liquidity, and it is the only thing standing behind the price.

Every purchase moves the price against you

Take shares out and the pile has fewer left, so the next ones cost more. A deep pile barely notices a small order. A thin one lurches. The gap between the price you saw and the price you actually paid is what this site calls the cost to fill.

And then the pile runs out

This is the part nobody quotes. Liquidity is not spread evenly: it is deposited in bands, and past the last band there is nothing left to sell you at any price. Every venue hits that wall at a different size, and until you look, it is invisible.

The same share sits in six different piles

Six venues each keep their own NVIDIA pool on this chain. They do not talk to each other, so at any instant they disagree about the price, and the cheapest of them is often the shallowest, which is exactly the trap. Measuring both of those at once is the whole of what KUDARO does.

A price tells you what one share costs. It tells you nothing about what a thousand cost, or whether the venue quoting it can sell you a thousand at all. KUDARO exists to publish the second number.

It does three things and refuses a fourth:

Reading one geometry as another is not a rounding error. An Algebra pool read as constant product puts a quote tens of percent away from the market. So each kind gets its own path, and a venue whose kind cannot be established is excluded rather than guessed at.

Decoding is positional, not ABI-shaped

Several forks on this chain return one word fewer from slot0() than Uniswap does. A strict ABI decoder throws on that and the venue disappears from the book entirely. KUDARO reads the returned words by position instead, so a fork with an extra field, or one missing, still prices.

export function word(data: `0x${string}`, i: number): bigint {
  const start = 2 + i * 64;
  const hex = data.slice(start, start + 64);
  if (hex.length < 64) throw new Error(`word ${i} missing`);
  return BigInt('0x' + hex);
}

Everything goes through Multicall3

A single KUDARO is hundreds of storage reads. They are batched into one eth_call against the canonical Multicall3 deployment, which is present on this chain at the usual address.

slot0()         0x3850c7bd      ticks(int24)       0xf30dba93
globalState()   0xe76c01e4      tickBitmap(int16)  0x5339c296
liquidity()     0x1a686502      getReserves()      0x0902f1ac
token0()        0x0dfe1681      extsload(bytes32)  0x1e2eaeaf
token1()        0xd21220a7      balanceOf(address) 0x70a08231
fee()           0xddca3f43      tickSpacing()      0xd0c93a7c

Venues that hide their pair

Some forks expose reserves but revert on token0() and token1(), and do not order their reserves by token address either. Guessing the orientation inverts the price. KUDARO establishes it by asking each token how much the pool holds of it and matching that against the reserves, entirely on chain, no directory involved.

In a v4-style AMM every pool lives inside one shared contract. State is reached through extsload, keyed by a 32-byte pool id, and the slot is computed rather than queried.

slot = keccak256(abi.encode(poolId, POOLS_SLOT))

  +0   slot0 = lpFee(24) | protocolFee(24) | tick(24) | sqrtPriceX96(160)
  +1   feeGrowthGlobal0X128
  +2   feeGrowthGlobal1X128
  +3   liquidity
  +4   ticks       mapping(int24  => TickInfo)
  +5   tickBitmap  mapping(int16  => uint256)

The two singletons do not agree

They keep the pools mapping at different slot numbers. Nothing published states either one; both were established by hashing a known pool id against each candidate until state came back.

tickSpacing is not in storage

It belongs to the pool key, not to the pool’s state, so it cannot be read back from the singleton at all. Defaulting it would silently produce a pool with no initialized ticks: indistinguishable from a pool that has genuinely run dry. KUDARO probes instead: the correct spacing is the one whose bitmap actually lights up.

KUDARO finds that point by replaying the pool’s own swap loop against its own tick data, in the same 256-bit integer arithmetic the contract runs. Not a curve fitted to trades. Not an estimate.

while (remaining > 0n && sqrtP !== limit) {
  const next = ordered[cursor];              // next initialized tick ahead
  if (next === undefined) { exhausted = true; break; }

  const step = computeSwapStep(sqrtP, target, liquidity, remaining, feePips);
  remaining -= step.amountIn + step.feeAmount;
  amountOut += step.amountOut;
  sqrtP      = step.sqrtRatioNextX96;

  if (sqrtP === target) {                    // crossed a tick
    liquidity += zeroForOne ? -next.liquidityNet : next.liquidityNet;
    cursor++;
  } else break;                              // filled inside this band
}

When the input exceeds what the pool holds, the fill comes back marked exhausted together with the amount actually absorbed. Nothing is extrapolated past that point, which is why a venue’s line on the charts simply ends: a short line is a fact about that venue, not a gap in the data.

The ladder

Every ticker is KUDARO at a fixed set of order sizes, in dollars:

$100   $1,000   $5,000   $25,000   $100,000   $500,000   $2,000,000

Constant product has no wall

It never runs out: it just gets arbitrarily expensive. Reporting that as bottomless would publish an eight-thousand-dollar pool as absorbing past two million. So a constant-product venue reports the last size that still fills for less than the order is worth, and the site marks it with an asterisk to say the limit is of a different kind.

Dispersion is the gap in basis points between the cheapest and the dearest venue at one block. Three rules decide which venues are in it. Each of them makes the headline smaller.

A drained pool is not a quote

A pool that has been emptied keeps whatever price it was abandoned at, forever, and that stale number will sit in aggregate feeds looking like an opportunity. Only venues holding enough depth to fill the smallest rung on the ladder count towards the spread. The rest stay in the table, labelled.

A ticker is not an identity

Several tokens answer to the same symbol on this chain. Resolving by name alone is how a book ends up quoting a nine-cent impostor beside a two-hundred-dollar share. Every ticker resolves to the address whose pools carry the turnover, and the ones dropped are recorded rather than hidden.

An unclassified venue is dropped

11 venues have an explicit read path. Anything else is excluded from the book. That is why the venue list is shorter than the number of names on the chain, and why nothing on it needs a caveat.

For every size on the ladder, the engine buys on each venue and tries selling the proceeds on every other one, using each pool’s real state in both directions. Both fees and both price impacts are already inside the result. No extra chain reads are needed: the state has already been fetched.

What is not inside it: gas, the risk that someone else takes it first, and the fact that both pools move the moment anybody acts. It is a measurement of a disagreement, not a promise of profit, and most of the time it comes back at nothing at all.

{
  sizeUsd, tokens, returnedUsd, profitUsd, profitBps,
  buy:  { ref, label, pair },
  sell: { ref, label, pair }
}

Something has to say which pools exist. That is the only job an indexer does here: npm run canon walks it, resolves which address carries the real market for each ticker, records which pools quote it, and writes the result to disk. From then on a page load is chain reads and nothing else, so a rate limit somewhere else cannot change a number published here.

Current registry: 462 pools and 49 tickers, last recomputed 2026-09-04 10:35 UTC. A ticker that appears after that falls through to live discovery instead.

GET /api/novarch?ticker=NVDA
GET /api/novarch?ticker=SPY&sizes=100,1000,25000

  ticker   symbol, or a 0x address
  sizes    optional, comma separated, in dollars, up to nine

Responses carry s-maxage=20 with stale-while-revalidate, so bursts are served from cache rather than from the chain. A reading is only true for the block it names.

https://novarchliq.site/?ticker=SPY&size=100000

The same endpoints the card calls are open to any app, with CORS on, no key, no sign-up. Route through KUDARO and your users get the measured route, the floor our contract enforces, and the burn on every fill.

GET /api/route?ticker=NVDA&size=350&payAmount=350&pay=USDG&mode=executor&tolerance=50

  ticker      symbol, or a 0x address (any token on the chain)
  pay         USDG or WETH
  payAmount   exact quantity of the paying token; size is its dollar figure
  tolerance   slippage in basis points, 1..1000 (default 50)
  mode        executor: the ticket is written to be sent through our contract

  ticket        { data, tokenIn, tokenOut, amountIn, expectedOut, route }
  executorFloor the least the caller accepts, enforced on chain
  simulation    { accepted, chainOut, driftBps, calls }  — what the chain paid, measured
  saved         { headlineUsd, vsAverageUsd, ... }
  passedOver[]  venues that read cheaper and paid less, in the chain's words
  fee           { amount, usd }  — the SOUNDER burned by the fill

GET /api/sell?ticker=PONS&amount=500&quote=USDG&tolerance=50

GET /api/compare?tickers=NVDA,AAPL,TSLA&size=25000

  rows[]   { symbol, spotUsd, fillUsd, costBps, venue, spreadBps, capacityUsd, fillable, venues }
           cheapest first; costBps null where no venue absorbs the size

POST /api/route   { "ticker": "NVDA", "size": 350, "payAmount": 350, "pay": "USDG", "mode": "executor", "tolerance": 50 }

To sign a ticket, call fill(tokenIn, amountIn, tokenOut, executorFloor, deadline, ticket.data) on the executor at coming soon, after the three approvals described under contracts. The executor counts what arrives and reverts below the floor; the router is never trusted with it.

npm run book NVDA     KUDARO one ticker: every venue, the full ladder
npm run pulse         the whole watchlist, the way the board computes it
npm run canon         rebuild the registry: the only step that uses an indexer

The engine is plain TypeScript with no service behind it. Point SOUNDER_RPC at any node for Robinhood Chain and the numbers come out the same, because they come out of the chain.

JSON-RPC request batching is a trap here

Coalescing reads into JSON-RPC batches made six parallel KUDARO readings take 13.4 seconds. Sending them as concurrent single requests takes 0.9 seconds. Everything that can be bundled is already one eth_call through Multicall3, so a second layer of batching buys nothing and costs an order of magnitude.

Order endpoints by measured latency

robinhood-rpc.publicnode.com answers an eth_call in about 60 ms; the official endpoint spikes past two seconds. Archive log queries go the other way: publicnode refuses them, the official endpoint serves them.

A full KUDARO of a pool with four hundred initialized ticks lands in roughly 480 ms; the whole watchlist, with depth, in about 1.1 s.

Every swap made through the executor burns a fixed quantity of SOUNDER: the contract pulls it from the caller’s own wallet and sends it to a dead address before the route runs, inside the same transaction. It is the same quantity for a hundred-dollar order and a fifteen-thousand-dollar one, and it is enforced by the contract rather than asked for by the page: no SOUNDER, no fill. It is not collected by anyone. There is no treasury it accrues to, no multisig that later decides what to do with it, and no address we control in the path.

Why the fee is paid in the token

The obvious design charges the fee in whatever is being bought and buys SOUNDER with it later. That does not survive contact with this chain. Every SOUNDER pool here charges between 0.9% and 70%, and the only one holding liquidity charges 70%, so routing a fee through it would hand two thirds of every burn to somebody else’s liquidity providers and still call the result a burn.

Charging in the token itself avoids the question. Nothing is bought, so no pool is needed, no route can be sandwiched, and no vault accumulates anything worth stealing. A hundred per cent of what is charged is destroyed, which is a claim that can be checked one transaction at a time.

What the burn is, against what the routing is worth

The honest way to present a fee is beside the thing it is charged for. Measured across five tickers at a hundred dollars, sending an order to the venue KUDARO picks beats choosing one blind by a median of 8.6 basis points, and by as much as 393 against the worst venue quoting the same ticker.

At 50 basis points the fee sits above every one of those medians and below the worst-case column. Read plainly: it pays for itself when it saves you from a bad venue, and it does not when you would have picked an average one anyway. On a chain where the same ticker trades across nine places at once, how often that happens is a question you can answer with the tool itself before you use it. Every venue, and its cost at your size, is on the KUDARO page.

What it is not

What the token does is one thing: it is what using KUDARO costs, and using KUDARO is what removes it. Whether that is worth anything depends entirely on whether people route through the tool, which is a question about the tool rather than a promise about the token.

The indexer’s pool names are not trustworthy for ordering: it prints “USDG / WETH” for a pool whose token0 is WETH. Every pair is established by reading symbol() and decimals() off the tokens themselves.

1. 2026-09-15

   The terminalnew

   Every page on KUDARO behind one prompt, at novarch.app/terminal. Type a ticker and it is KUDARO at your size, with the ladder under it. Type size 100k and every reading and the watch column use it. Type buy 25k NVDA or sell 100 NVDA and the swap card opens filled in. compare, walls and orders answer in place; watch keeps a column of names re-KUDARO every thirty seconds with how each fill moved, in bps, since the last tick. Up and down replay, tab completes a ticker, and the board lives in the link. Underneath it is the same open API as everything else, plus a new one: GET /api/compare.

2. 2026-09-15

   Comparenew

   Several tickers, one size, one minute. novarch.app/compare KUDAROs up to eight names in full and ranks them by what the fill actually costs at the size you pick: the realised price, the venue it is on, how far the venues disagree, and how much the chain can take before it walls out. The board lives in the link, so novarchliq.site/compare?tickers=NVDA,AAPL,TSLA&size=25000 is the board, and its preview is drawn from the chain when someone opens it.

3. 2026-09-14

   Every KUDARO link shows its cardnew

   Share a KUDARO and the link now carries its reading. Paste novarchliq.site/sounding?ticker=NVDA into a tweet, a chat or a message and the preview that appears is drawn from the chain when the link is opened: the ticker, the block it was read at, the best fill at the size and the venue it is on, the spread across the venues that can actually be filled, how much the chain can take. It is a picture of a reading, cached a minute, never a stored quote, and it says so on the card. The same picture is at /api/og?ticker= for anyone who wants it.

4. 2026-09-14

   Build on KUDAROnew

   An SDK, and a page for it. One file with no dependencies, served from the site as sdk.mjs with its types beside it: KUDARO a ticker, get the best route the chain accepts written and measured, the three approvals, the executor call with the floor inside it, the order book, a limit order to leave, a fill anyone may send, the depth map, the peg. It never holds a key; every method hands back a plain { to, data } on Robinhood Chain and you sign it with whatever you sign things with. The encoders were checked byte for byte against viem before shipping. What it means: any app on this chain can give its users KUDARO’s routes and KUDARO’s floor in twenty lines, and every fill that goes through burns SOUNDER, whichever front end asked.

5. 2026-09-14

   Orders that waitnew

   Until now KUDARO was a place you came to with a decision already made: take the KUDARO, sign the fill, leave. It is now also a place where money can wait. Leave what you are paying and the least you will accept back, and a new contract, KUDAROOrders at 0x4CF73434058FdBd27a96477B4378FDcFFef3f2bB, holds both — the input, and the SOUNDER the fill will burn — until the chain can fill the order or you take it back. Nobody else can touch either; the owner can always cancel, and no one but the owner can. Execution is permissionless. Anyone may send the fill with a router instruction; the contract does not trust it, it measures its own balance of the output before and after and reverts the whole transaction if the count is below the floor. The output goes to the owner, never to whoever sent the fill; the unspent input goes back to the owner; the escrowed SOUNDER goes to the dead address in the same transaction; and a route may spend only the order it is filling, never another order’s escrow — eight tests, all of them about that. The page reads the book from the contract and tries every open order against the chain on every load, so an order the chain would fill right now says so with the exact number, and a button sends it from any wallet. There is a keeper script too, for anyone who wants to run one with a key of their own; the site never holds one. Same ceilings, same burn, same keeper dials as the executor, logged.

6. 2026-09-14

   The depth mapnew

   A new page: every ticker on Robinhood Chain, walked at four sizes — a thousand, ten thousand, a hundred thousand, a million dollars — in one reading. Each cell is the cheapest venue that absorbs that size and what it costs there in basis points, fee included, read from the pool’s own ticks; a wall is where nothing on the chain can. Rows run from deep to thin by what the chain can take in total, and every row links to its full KUDARO. The first reading, at block 62,659,530: forty-eight tickers, a hundred and ninety-two cells, fifty-seven of them walls. SPY takes a thousand dollars for 0.3 basis points and a million for 49. PONS, the deepest name on the chain by capacity, takes a million for 761. TSLA, MSTR, AAPL, META and LLY wall out before a million. Four names fill nothing at any size. The whole map read in under twenty seconds and is cached for fifteen minutes, so the page is a picture of the chain a quarter-hour old at most, stamped with its block. It is what we had been building towards all week: not a price for a ticker, but the shape of the whole chain.

7. 2026-09-12

   The peg, watchednew

   We said the burn would be re-pegged as SOUNDER moves. Here is how, in the open. The rule: the quantity targets two dollars, and when its value drifts more than twenty percent either way the keeper sets a new one. The watching: /api/peg reads the quantity from the contract, prices it at spot, says the drift, says whether a re-peg is due, says what quantity would hold the target today, and lists every re-peg the contract has ever logged as a BurnSet event. The contracts page carries the same line. The keeper still signs — a contract cannot price SOUNDER honestly, and we would rather have a human hold that pen with the numbers public than a bot hold a key — but there is nothing left to take our word for: the rule is written down, the drift is measured, and the change, when it comes, is on chain.

8. 2026-09-12

   Two hops, one transactionnew

   Some tokens on this chain only quote against WETH, and until today that meant a buyer holding USDG had no route: the card said no venue, and it was right. It now builds the route in two legs. The paying token goes into the best money-leg pool and comes out as the middle token, the router keeps it, and the token’s own pool takes all of it in the same transaction. The floor is on the final token only, enforced by our executor on its own balance as ever; the middle leg is never the caller’s to worry about. Every pairing of money leg and token leg is measured through the executor, and the one the chain pays most on is published, with both legs named. Two things were learned on the way. The registry’s WETH entry is all v4 pools and several of them are native-ether pools: hand the router ether where the next leg expects the wrapped token and the singleton refuses the whole transaction as unsettled, so the money leg is held to pools whose two currencies are exactly USDG and WETH, and the v3 pool the site prices ether from is always a candidate. Measured today: a hundred USDG into CHUMP, which quotes only against WETH — Uniswap v3 into Uniswap v3, 2,403.63 CHUMP, one call, the floor at 2,391.61. The direct route is still preferred wherever one exists; the second hop is only built when there is none.

9. 2026-09-12

   The burn, pricednew

   Small one. The burn is a fixed quantity of SOUNDER, which is what a contract can enforce exactly, and the dollar figure it amounts to drifts with the token. The card now shows both on every route: the quantity, and what it is worth at the last reading. The contracts page carries the same line, read from the contract and priced at spot each minute. And the re-peg has a script: it says what quantity holds the burn at a target figure today and prints the one command the keeper signs. The peg is a keeper decision, made in the open; the script only does the arithmetic.

10. 2026-09-11

    Route through KUDARO from any appnew

    The endpoints the card calls were always reachable; they are now open on purpose. CORS is on for the whole API, preflights are answered, there is no key and no sign-up, and the docs carry the contract: what to send, what comes back, and how to sign a ticket. Any app on Robinhood Chain can ask for the best buy or sell the chain accepts, get it written and measured through our executor, and hand its users the floor that contract enforces. Every fill that goes through it burns SOUNDER, whichever front end asked. The quiet-mode form, an order in a request body with nothing cached, is open too.

11. 2026-09-11

    Any token on the chainnew

    The card took a ticker from a list of forty-four. It now takes a contract address too: paste one into the search and the KUDARO, the route and the fill run on that token whether or not anyone has listed it anywhere. This was mostly already true underneath — the KUDARO has read pools by address since the first week, and the key index knows every v4 pool on the chain, listed or not — and what was missing was the door. A pasted address is offered as a ticker, the chip shows the short address until the chain answers with the token’s own symbol, and the three endpoints accept a full address where they used to cut a ticker at twenty-four characters. Tried on a token nobody has listed: a hundred dollars of cyberbeer, twelve pools read, one that fills, the best route written and measured through our contract in one call. Selling an unlisted token needs a ceiling on the executor first, so for now an unlisted address buys; the keeper can teach the contract any token in one transaction when it is asked for.

12. 2026-09-10

    Quiet modenew

    Someone asked for a privacy mode for large orders, and the honest answer comes first: there is no such thing on this chain. Every transaction on Robinhood Chain is public, and no shielded pool is deployed here for us to route through, so a private swap is not something we can offer, and we will not use the word. What we can do is make sure nothing about an order leaks before it is sent, and that the sending can happen from a wallet nobody has seen. That is quiet mode, a switch on the card. In it, the order travels in a request body rather than a query string, so it never appears in a URL — not in a browser’s history, not in our host’s request log. Nothing is written to the page address, the instrument, or storage; the answer is marked not to be cached; and the mode itself lives in memory only, so a reload forgets it. The KUDARO was never a transaction — it is an eth_call, and nobody sees an intention — and that has not changed. And the executor call is handed over as text: the three approvals and the fill, with the floor inside it, to be signed from any address, including one funded a minute ago. Normal mode is unchanged, and remains the default.

13. 2026-09-10

    The route is chosen by what the chain paysnew

    Until today the route was the cheapest reading the chain would accept: candidates in cost order, the first one the chain ran was the one published. That is right for a plain pool and wrong for a hooked one. Nearly half the v4 pools on this chain carry a hook, and a hook takes its toll inside the swap, where a KUDARO cannot see it: the pool reads one number and pays another. Measured today at 350 dollars of NVDA, the hooked pool read 3.6 basis points behind the best venue and paid 13.6 behind it; at a thousand dollars of SPY, the hooked pool paid 8 basis points less than it read and was still the best fill on the chain by 48. So the choice is made differently now. The first three candidates the chain accepts are all measured, through our contract, one call each, and the one the chain pays most on is the route. When the chosen pool carries a hook, the card says what the hook took, in basis points, measured rather than assumed. The venues passed over say why in the same terms: what they read against the winner, and what they paid. Selling chooses the same way.

14. 2026-09-10

    The other direction, KUDAROnew

    The card faces both ways now. Turn it, type a quantity of a ticker, and the KUDARO replays the same pool state the other way: the token is the input, and what comes out is USDG or WETH, priced in dollars at its rate, measured on chain for that order in that block, with the floor and the burn under it. Getting there took a borrowed caller. Our simulation funds an address that does not exist by writing its balance into the token’s storage for one call, and the tokenized stocks here sit behind a beacon proxy whose implementation keeps balances somewhere our search cannot find. So for those tokens the simulation borrows a real holder instead: an address that already holds enough of the token and has already granted Permit2 an allowance, found in the chain’s own approval logs. Nothing of theirs moves; the call is never sent. They lend the shape of their balance to one eth_call. What is not yet there is the signature. The second executor moves two input tokens, the money legs, and their ceilings were written once at construction. Selling makes every ticker an input token, and a new asset must not mean a new address and everyone re-approving. The third executor is written and tested: the same contract, with ceilings the keeper sets per token, on one address for as long as the project runs. The sell side signs the day it is deployed and the page is pointed at it; until then the card says so, in those words, under a number that is already real.

15. 2026-09-10

    One place to buynew

    The swap card is now the only place an order is placed, on a phone and on a wide screen alike; the panel that used to sit under the instrument is gone. What it carried moved into the card: what the route saved against the average venue, the legs of a split with their shares, the floor, the burn, and the venues that looked cheaper and were refused by the chain, in the chain’s words. Taking a KUDARO from the card moves the instrument to the same ticker at the same size, so the depth drawn beneath is the depth that order was priced against, not a preset next to it.

16. 2026-09-09

    The swap as a card, on a phonenew

    On a phone the KUDARO page now opens on the two lines people expect from a swap: what you pay, in USDG or WETH, and what you get, with the ticker chosen from a searchable list of everything this chain quotes rather than typed into a field. A name that is not on this chain says so instead of quietly failing. Slippage is a row of four; the button takes a KUDARO, and the number that appears is not a quote but what the chain returned for that order in that block, with the route, the floor and the burn written under it. Paying in WETH sends exactly the quantity typed, not the dollar figure it rounds to. Building it turned up a measurement fault worth owning: for v3 routes, the way we squeezed the output out of the router — raising the floor until it refused — could not work, because this router does not enforce the v3 minimum at all, and so the “measured” number for those routes was the ceiling of the search, a fifth above the reading. The simulation now runs the order through our own executor with a floor no trade can meet; the contract counts what arrived and refuses with that count, which is exact, one call, and the same for every venue class. Orders the executor will not take are still asked of the router directly, and where the router cannot be squeezed the reading is published as the reading, not as a measurement. The instrument itself is unchanged, and on a wider screen nothing moved.

17. 2026-09-09

    Any size, and a burn the contract enforcesnew

    Two things people asked for on the day V2 went live, done. The instrument takes any dollar amount now, typed, rather than the seven rungs of the ladder: a typed size is added to the ladder the KUDARO walks, so the route and the floor are measured at exactly that number and not at the nearest preset. And there is a second executor. The first one enforced the floor and took nothing; the burn was a separate transaction the page asked for, which meant anyone could skip it. The second, at 0x23bba991850892d78B5c6802BaD59BDBeFBBc3c4, does the burn itself: every fill pulls a fixed quantity of SOUNDER from the caller and sends it to the dead address before the route runs, inside the same transaction. No SOUNDER, no fill. It is a quantity of tokens rather than a share of the order, because a contract cannot price SOUNDER honestly and a fixed number is something it can enforce exactly. The quantity is set on the contract and readable there, and the address that deployed it can re-peg it as the price moves, which is the one adjustable thing on it. The page asks for a bounded allowance, ten burns’ worth, never unlimited, so a re-peg can never reach more than a caller knowingly granted. The first deployment stays where it is and still works; the page no longer writes to it.

18. 2026-09-09

    Every v3 pool on this chain was unreachable, and now none of them arenew

    This router has always refused the v3 path. Every pool, every ticker, the same answer: SliceOutOfBounds, which is a bounds check failing rather than a complaint about anything we wrote. A v3 path is packed bytes — token in, fee, token out — and at its natural forty-three bytes this router will not read it. Padding it and sweeping the length showed exactly where it starts working: sixty-four bytes, and from sixty-six it is read as a second hop instead, so the window is two bytes wide. What goes in the padding is irrelevant; zeros, ones and a repeated address all return the same amount, so the extra span is skipped over rather than read. Some constant in this fork is larger than the one upstream and sixty-four is where it lands. Past that came a second wall, and it is the more awkward of the two: any non-zero minimum output makes the router answer 0x383ef61c, including one wei on a swap returning 5.9e15 of the token, so that field is not being read from where we write it. We have not worked out where it is read from and would rather say so than pretend. The router’s minimum is therefore set to zero for v3, which is safe here for the reason it was always safe: the floor has never been the router’s job on this site. The executor counts its own balance before the route and after, and reverts everything if the difference comes up short. Anyone taking this calldata and sending it straight to the router gets no floor at all, and the transaction the page builds does not do that. The effect is not small. Forty-three of forty-five tickers now fill a thousand dollars, against thirty this morning, and for twenty-seven of them the cheapest route the chain accepts is a v3 pool — a venue class that could be quoted here since the first day and never once traded. Splits can use them too: twenty-six of twenty-six planned splits were accepted, fourteen of those paying a v3 pool and a v4 pool inside the same transaction. Two tickers are still refused, one by an unsettled currency and one by a token whose storage our simulation cannot map.

19. 2026-09-09

    Four of the biggest names on this chain could not be traded, and it was our faultnew

    AMC, TSLA, COST and SPY have been refusing every route KUDARO wrote for them, on every pool, with a revert that carried no name: 0x4713c18b and two numbers. It was not the tokens: they are the same 283-byte proxies as the ones that work, and a plain transfer of any of them goes through. It was not the singleton either. The selector turned out to be in the router’s own bytecode, which means the router was throwing our instruction out before a pool ever saw it, and the two numbers were the price limit we had supplied and the pool’s current price. Every v4 swap carries a sqrtPriceLimitX96, a price past which the swap should stop. The textbook value when you are buying the first of the two tokens is the maximum square-root price, because the price is moving upward and the limit sits above it, and that is what KUDARO sent. This router rejects it. Sending zero works, in both directions, and so does the minimum; all three return the same amount, so the limit was never binding on these sizes to begin with. Whether that is a fork’s inverted check or a validation of its own, we cannot say from the outside, and we would rather write down what we measured than guess at a cause. The rule is now simply no limit, which is safe here for a reason worth stating: the router still enforces amountOutMinimum on the swap itself, and our executor still enforces the floor on its own balance afterwards, so the number that matters is checked twice. What decided which tickers broke was nothing more than address ordering. AMC, TSLA, COST and SPY sort below USDG; that put their swaps on the failing side of the limit, and it is why the bug looked like it was about those companies when it never was. Thirty of forty-five tickers now fill a thousand dollars where four of the largest filled nothing. The rest are refused by this router’s v3 path, which is a different problem and still open.

20. 2026-09-08

    The number that was already there

    KUDARO has been sending several routes to the chain in the same block for a while now: that is how a route gets offered at all, and since this morning it is how the split gets chosen. What it did with the losing answers was throw them away. It no longer does. Above the swap button there is now one figure: what this route was worth, in dollars of the thing you are buying, against the average of every other venue the router can reach that quotes this size. On AAPL at a hundred thousand dollars that is 1,367 dollars more Apple for the same money; a hundred and ninety-one of it comes from splitting the order and the rest from not going where an indexer would have sent you. Every number in it is a subtraction between two results the chain returned in the same block, which is the only reason it is worth printing: nothing here is a modelled price, an estimate, or a comparison against a market rate nobody could have got. Underneath, in small type, the same figure is broken into the part won by splitting and the part won by seeing pools nobody lists, because those are different claims and lumping them together would flatter both. Where no pool an indexer lists can fill the size at all, which on this chain is not rare, it says that instead, because it is a stronger fact than any number.

21. 2026-09-08

    An order does not have to go to one pool

    A depth curve bends. The first dollar into a pool buys more than the thousandth, so past some size the cheapest pool stops being the cheapest way to buy: its own price impact overtakes the next pool’s fee. KUDARO has been walking those curves since the first day and then throwing the shape away, sending the whole order to whichever venue won at the top. It no longer does. The order is handed out in fortieths, each one to whichever pool pays most for it at that moment, which for concave curves is the optimum and needs no solver. The result is a single transaction that pays several pools: the Universal Router takes a list of commands, so a split is not a new mechanism, it is the same instruction written more than once. Nothing about the executor changed, and nothing needed to: it counts what its own balance did, and a balance does not care how many pools contributed. Measured on chain rather than promised: AAPL at a hundred thousand dollars returns 18.5 basis points more across two pools than in the best single one, SHROOM at five thousand returns 30.4 across four, and a thinner name at twenty-five thousand returned 272.6 across three. It is also, deliberately, not trusted. NVDA at twenty-five thousand was predicted to gain eighteen basis points and actually lost eight, because the arithmetic was wrong about one of the pools. So the split is written, sent to the chain alongside the single route it is competing with, and kept only when the chain returns more for it. When it does not, the page says so and the single route stands. One limit worth naming: every leg is a v4 pool, because this chain’s router answers SliceOutOfBounds to the v3 path, and a leg that cannot be sent is not a leg.

22. 2026-09-07

    The first one

    Everything here had been verified by simulation, which is a way of saying nobody had ever signed it. Transaction 0x89918e357dcd04828fcf5e7d2703836c32f5e178ad4e65189bc090fd69aba356, in block 56,806,453, is the first fill this site has ever written that a person actually sent: twenty-five dollars of USDG in, 0.593303 RBLX out, against a floor of 0.590337 that the executor checked on its own balance rather than took on trust. It cost 291,738 gas. The singleton logged the swap against pool 0xf807376333cd408c36d48a11a96309b92c5bd2bca9ba9f0b21800636cb3a30da, which is the point of it: that pool is in no indexer listing, it was found by reading the Initialize event that created it, and the alternative every other router would have taken, the v3 pool at 0x1bdb8e3a, is both 36 basis points more expensive and refused outright by this chain’s router. Two things went wrong on the way, and both are worth writing down. The first attempt called fill with a uint256 where the contract takes a uint160, which is a different selector, so the call landed on nothing and reverted with no reason at all; the fee had already been burned by then, so it cost real SOUNDER to learn. The second worked on the first try.

23. 2026-09-07

    A pool you can read is not yet a pool you can trade

    The key index landed yesterday on the reading side only, and the difference turned out to matter. A v4 swap has to hand the singleton the five fields that hashed into the pool id, and the execution path was still guessing them the old way: take the fee out of slot0, assume the tick spacing, assume there is no hook, hash it, and refuse the pool if the hash comes out wrong. That guess is right for the plainest pools and wrong for every hooked or dynamic-fee one, so a pool the KUDARO had just quoted could not be sent a transaction. Worse, the router only ever considered venues from the registry, which is the one place the recovered pools do not appear: they were quoted, ranked, and then dropped before anything was written. Both are gone. The key comes out of the index now, hook address and all, and reach is asked about the venues the KUDARO actually read. A hooked v4 pool is executable here for the first time. On RBLX at twenty-five dollars the effect is not subtle: the cheapest venue is a pool no indexer lists, it is 36 basis points better than the best one that is listed, and it is the only route of the two that this chain accepts at all: the listed one is refused by the router before it reaches a pool.

24. 2026-09-07

    The pools nobody could see

    A Uniswap v4 pool has no address: it is the hash of its key, so nothing can be read out of one until the key is known, and every indexer guesses that key from a fee tier and a tick spacing. On this chain there are 12,528 distinct fees in use, so the guess misses most of the market: measured against live traffic, KUDARO could read 21 of 313 pools that had just traded, about seven per cent of the swaps. The singleton announces the whole key when a pool is created, so the keys are now taken from those events instead of inferred. 608,809 recovered, each one verified by hashing it back to its own pool id; a key that does not reproduce its own pool is discarded rather than trusted. The 7,758 pools that people actually trade ship as a 2.4MB index, and because this chain makes ten blocks a second and hundreds of pools an hour, anything born since the index was written is picked up from the last twelve thousand blocks on demand: a pool that looks missing here is almost always just new. Coverage of live swap traffic went from 6.7% to 97.6%. A KUDARO on NVDA now reads sixteen venues where it read nine, nine of them v4 where it found three, in the same second.

25. 2026-09-04

    Using this page costs SOUNDER, and the SOUNDER is destroyednew

    A swap made from here pays fifty basis points, in SOUNDER, out of the caller’s own wallet, to a dead address. It buys nothing to make that happen: the token is already theirs, so it needs no pool, no route and no vault, and it burns every basis point of what it takes. That matters here more than it usually would: every SOUNDER pool on this chain charges between 0.9% and 70%, the only one holding liquidity charges 70%, and routing a fee through it would have handed two thirds of every burn to somebody else’s liquidity while still calling it a burn. Paying in the token itself avoids the question entirely. The number is published beside the thing it is charged for: across five tickers at a hundred dollars, going to the venue KUDARO picks beats the median venue by 8.6 basis points and the worst by as much as 393, so at fifty the fee pays for itself against a bad choice and not against an average one. It is a separate transaction on purpose, which is also the honest way to describe it: this is a fee charged by the page, not by the contracts. The executor cannot see it and does not enforce it, its address has not changed, and anyone building their own calldata can route around it.

26. 2026-09-04

    There is a button nownew

    Until today the site wrote a transaction and left it there: to actually run one you had to copy the calldata into a terminal, which is not a thing anyone was going to do. The KUDARO now carries the trade itself: connect a wallet, grant the two approvals if they are missing, and send it. There is no connector library and no vendored modal in the way; a wallet here is an EIP-1193 provider and nothing more, so nothing between the reading and the signature is code you cannot read. The order is unchanged and deliberate: the route is only offered once the chain has already run it, the floor is enforced by our own contract rather than promised by the router, and the router’s own minimum is left five basis points looser so the binding check is the one performed on a balance rather than on a promise. Neither approval is requested by the contract on your behalf. It is new, it is unaudited, and it is worth starting small.

27. 2026-09-04

    KUDAROExecutor: the floor is enforced now, not promisednew

    Deployed at 0xf4ab80f0b773a41907c365a77a73628f73750aba, superseded on 9 September by the second deployment, which the page now uses. A router will accept a transaction and hand back less than was quoted: its own minimum is checked inside the same contract that decides what you got. This one measures the change in its own balance, before the route and after it, and reverts if the trade came up short. The check does not depend on the router being honest or on KUDARO being right. It has no owner, no admin, no pause and no upgrade path; it holds nothing between transactions, sweeping both tokens back to the caller before the call returns; and it can only ever call one address, fixed at construction, with one function selector. Run against live chain state on a real NVDA route it filled within a hundredth of a basis point of the reading, refused a floor set above what the chain would pay, refused a stale deadline, and refused calldata that was not the router’s own execute. It is new and it is not audited, which is a fact about it rather than a disclaimer.

28. 2026-09-04

    KUDAROLens is on chainnew

    The first piece of KUDARO that is not a website. KUDAROLens is deployed at coming soon and answers the same questions this page does, from inside the chain, to anyone who asks. It has no owner, no admin, no upgrade path and no storage; every function is view, so it cannot hold a token or move one. It exists because of a mistake we made: a v4 pool keeps the LP fee and a protocol fee in the same word, the two do not add, and KUDARO had been charging only the first. `swapFee` is that composition where it can be checked instead of believed: for the NVDA pool it returns 3,498 pips against the 3,000 the pool advertises. Three thousand two hundred and forty-nine bytes, solc 0.8.26, and the constructor arguments are published so the deployed code can be reproduced exactly.

29. 2026-09-04

    The chain runs it, and it agrees to within one basis pointnew

    A route KUDARO writes is now executed against live chain state before it is published, and one finally passed. Getting there took reading the router rather than the documentation: its v4 swap parameters carry a sixth field, the price limit, that later versions of the periphery dropped: encode the five-field version and the call reverts with no data at all. It also wants paying first and takes last. With the right shape the transaction runs, and the output can be squeezed out of a function that returns nothing by raising the floor until the router refuses. The first honest comparison said the chain hands over 6.83 basis points less than KUDARO promised, every time, on every size. That gap was ours: a v4 pool can carry a protocol fee packed beside the LP fee, taken off the input before the LP’s share, and the two do not add: KUDARO was charging only the LP fee and reading five basis points rich on every v4 pool it has ever quoted. Composed properly, the disagreement is 0.97 basis points. The route that gets published is now the cheapest one the chain will actually run, and the ones passed over are listed with the reason.

30. 2026-09-04

    Gas is in the number nownew

    KUDARO used to publish the pool’s own price impact and say plainly that gas was not in it. That caveat is gone, and so is the asterisk. Nothing here is estimated: `eth_estimateGas` needs a transaction that runs, and the honest way to price a swap on a chain is to look at what the chain has been charging for one, so the receipts of real swaps in recent blocks are read and the median taken for each geometry. They are not the same: a v2 swap lands for about half of what a v4 swap costs. Because gas is charged per transaction rather than per dollar, it is a rounding error at the top of the ladder and the whole answer at the bottom: a hundred dollar order can pay more to be included than it pays the pool, and a venue quoting five basis points better is not better if reaching it costs more than that. The best fill is now chosen on the all-in price, which changes the winner at small sizes. The crossing is charged twice, because it is two transactions.

1. 2026-09-04

   The chain now has to agreenew

   Every route KUDARO writes is handed to the chain and run before it is called executable. The caller is a scratch address that does not exist, given the input token and its Permit2 approvals by overriding state for the length of one eth_call: nothing is signed, nothing is sent, no real balance is touched. Because the router returns nothing, the output is squeezed out instead: the same transaction is offered with a rising floor until the router refuses, and the last floor it accepted is what the chain was willing to pay. The first thing this found was our own claim. A route can be structurally reachable: the v3 path resolves by CREATE2 to the pool it was measured on, and at zero size the pool answers with its own error, so the instruction is arriving intact, and still be refused when it is actually run. That refusal is now printed on the page next to the transaction, in the chain’s own words, rather than quietly left out.

2. 2026-09-04

   From a reading to a transaction: the first step of executionnew

   The largest step this project has taken. KUDARO now writes the trade. Every KUDARO carries the unsigned calldata for the best route the chain’s own router will accept: the pool, the amount, and a floor derived from the fill that was just measured. Finding that router took reading the chain rather than a deployment list: the canonical Universal Router address does exist here, but its pool manager points at an address with no code, so it is a copy that cannot execute. The live one was found by following the chain’s own swap traffic, and its bytecode carries the v3 factory, the v4 singleton, Permit2 and the v3 init code hash as immutables: the same four addresses KUDARO already reads. Each route is proved before it is offered: a v3 path is resolved by CREATE2 back to the pool it was measured on, and a v4 key is hashed back to its own pool id. Most venues fail that test. For NVDA, four of nine are reachable; the forks were never built against this router, and one Uniswap v4 pool carries a hook, so its key cannot be rebuilt from the fee alone. Nothing is signed and no wallet is asked for.

3. 2026-09-04

   A dead pool no longer sets the spread

   A pool with no depth left keeps whatever price it was abandoned at. When a ticker had only one fillable venue, the spread fell back to counting those, and SOUNDER published a number with fifty-eight digits in it. Below two fillable venues there is nothing to disagree about, and the page now says so instead of printing a figure. Capacity is bounded the same way: a pool that keeps answering at eighty thousand times spot has not absorbed the order, it has been drained by it, and it no longer reports depth it does not have.

4. 2026-09-04

   Locked is not liquid

   A new section puts the reserves an indexer reports next to the depth an order can actually take out. Across eight equities it is roughly a third. Pools paired against other tokens, and pools holding a fortune against no trade, are excluded rather than counted: for NVDA alone that is $183M of reserves no dollar order can reach.

5. 2026-09-04

   Every reading has a link

   The ticker and the size now live in the URL, so a KUDARO can be posted, argued with, and reopened exactly as it was. It is read on the client rather than on the server, which keeps the page cached for everyone else.

6. 2026-09-04

   The crossing

   KUDARO now buys on one venue and sells on another, in simulation, through both pools’ own arithmetic, and publishes what survives the fees and the price impact. Most spreads survive nothing.

7. 2026-09-03

   Constant product gets an honest limit

   A constant-product pool never runs out, so an $8k pool was being published as absorbing past $2M. It now reports the size past which the fill costs more than the order is worth.

8. 2026-09-02

   Venues that hide their pair

   Some forks expose reserves but not token0() and token1(), and do not order the reserves by address either. The orientation is now established by asking each token what the pool holds of it, entirely on chain.

1. shipped

   Read the whole chain, not the easy partlive

   v4 pool keys recovered from the singleton’s own Initialize events rather than guessed from fee tiers, which is why 12,528 distinct fees stopped being a problem. 608,809 keys, each verified against its own pool id; the traded ones ship as an index and the rest of the chain is caught on demand. Live swap coverage went from 6.7% to 97.6%.

2. shipped

   The floor, enforcedlive

   KUDAROExecutor counts what actually arrives and reverts if the trade comes up short, rather than trusting the minimum a router checks against itself. No owner, no admin, no upgrade path, nothing held between transactions. New, and not audited.

3. shipped

   A contract of our ownlive

   KUDAROLens: the fee composition and the pool readings, deployed on chain where they can be checked rather than believed. View only, no owner, no storage: it cannot hold a token. It is the small half of the contract work; the executor is the half with other people’s money behind it.

4. shipped

   Read the whole chainlive

   Four pool geometries, each with its own read path, including Uniswap v4, where no pool contract exists and state comes out of the singleton’s raw storage. 493 pools indexed, 59 tickers.

5. shipped

   Walk the depthlive

   The pool’s own swap loop, replayed tick by tick, to find where each venue stops absorbing. Nothing extrapolated past that point.

6. shipped

   Test the spreadlive

   Buy on one venue and sell on another, both legs simulated through real pool state. Publishes what survives the fees and the impact, usually very little.

7. shipped

   Write the transactionlive

   The first step of execution, and the largest one taken so far. Every KUDARO now carries the unsigned calldata for the best route the chain’s own router will accept: proved before it is offered, a v3 path resolved by CREATE2 back to the pool it was measured on and a v4 key hashed back to its own pool id. It holds no funds and asks for no signature; everything after this point is the signing.

8. next

   Alert on a takeable spreada week

   The engine computes whether a disagreement can actually be crossed. Watching a ticker and firing when it clears a threshold is the same computation on a timer.

9. after that

   Keep the readingsweeks

   Every KUDARO is currently thrown away. Persisting them gives depth and dispersion over time, which is the only way to tell a structural gap from a passing one.

10. after that

    Audited, then opened upweeks, and contracts on chain

    The transaction is written, the chain runs it, a contract of ours enforces the floor, and the page will now take a signature. What is left is the part that cannot be rushed: someone who breaks contracts for a living looking at this one, and only then an invitation for anyone else to route size through it.

Not on the roadmap

• Holding funds, ever.
• Publishing a number we cannot derive from chain state.
• Quoting a venue whose geometry we have not classified.