Two contracts of our own.

KUDARO spent its first weeks measuring: reading four pool geometries out of their own storage, walking depth tick by tick, and publishing what each venue could actually absorb. All of that ran on a server we control, behind a domain we own. Every figure on this site could have been made up, and you would have had no way to tell short of rebuilding the whole thing.

These two contracts close that gap from opposite ends. The lens lets anyone take the same reading without asking us. The executor makes the reading binding: it will not let a trade settle for less than was promised, and it does not take our word for what arrived: it counts.

A router will accept your transaction and hand back less than it quoted. Its own minimum is real, but it is checked inside the same contract that decides what you got, which is fine right up until it is not. This one sits outside that loop.

The router, the allowance system and the token it burns are fixed at deployment and there is no function that can change them. It can only ever call one address, with one function selector. Calldata that is not the router’s own execute is rejected before anything moves.

Every fill burns a fixed quantity of SOUNDER, pulled from the caller straight to the dead address before the route runs. If the caller cannot pay it, there is no fill. It is a quantity of tokens rather than a dollar figure, because a contract cannot price SOUNDER honestly, and the address that deployed it can re-peg the quantity as the price moves.

The burn is re-pegged by a rule rather than a mood: the quantity targets two dollars, and when its value drifts more than twenty percent either way the keeper sets a new one. Every change is a BurnSet event on the contract; the drift, the quantity that would hold the target today, and every re-peg so far are read live at /api/peg. Nobody has to be believed about it.

This third deployment exists for selling. Buying needed two input tokens, the money legs, and their ceilings could be written once at construction. Selling makes every ticker on this chain an input token, and a new asset must not mean a new address and everyone re-approving. So the ceiling for an input token is set by the keeper, per token, on this one address. A token with no ceiling is refused outright. That and the burn are the two adjustable things on it; there is still no pause, no upgrade and no fee recipient, and no way to touch anyone’s balance: a ceiling only bounds what one call may move through here. The earlier deployments stay on chain and still work. The page no longer writes to them.

Leave what you pay and the least you will accept back. The contract holds the input and the burn until the chain can fill the order or the owner takes it back; nobody else can touch either. Execution is permissionless: whoever sends the fill supplies the router instruction, the contract 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 the executor; the unspent input goes back to the owner; the escrowed SOUNDER goes to the dead address in the same transaction. A route may spend only the order it is filling, never another order’s escrow.

The contract records its own balance of the token you are buying, runs the route, and records it again. The difference is what actually arrived. If that number is below the floor you set, the whole transaction reverts and nothing has moved.

uint256 before = IERC20(tokenOut).balanceOf(address(this));

(bool ok, bytes memory reason) = router.call(routerCalldata);
if (!ok) revert RouterReverted(reason);

received = IERC20(tokenOut).balanceOf(address(this)) - before;
if (received < floor) revert TooLittleReceived(received, floor);

That check does not depend on the router being honest, on the pool being what we think it is, or on KUDARO having read the depth correctly. It depends only on arithmetic the contract performs on its own balance.

A v4 pool has no contract of its own: its state lives in a singleton’s raw storage, which is why most tools quote v4 badly or not at all. The lens reads that storage directly and hands back price, tick, liquidity and, crucially, the fee a swap is actually charged.

What it answers

A Uniswap v4 pool keeps two fees in the same storage word. There is the LP fee it advertises, and beside it a protocol fee taken off the input before the LP’s share is charged. The two do not add, and charging only the first understates what a swap costs.

KUDARO charged only the LP fee and read about five basis points rich on every v4 pool it quoted, for weeks, and nobody noticed, including us. It surfaced when the chain was finally asked to run one of KUDARO’s own transactions and disagreed by 6.83 basis points. Composed properly, the disagreement is under one.

protocol first, off the input; the LP's share on what is left

swapFee = protocolFee + (lpFee * (1_000_000 - protocolFee)) / 1_000_000

for the NVDA pool: 500 + (3000 * 999_500) / 1_000_000 = 3,498 pips
                   not 3,000, and not 3,500

the composition, as the contract performs it

The lens goes further: every function on it is view, so it cannot hold a token or move one under any circumstances. The executor holds your tokens only for the length of a single call, and a balance left in it afterwards is a bug rather than a policy.

cast call SOON \
  "swapFee(uint24,uint24)(uint24)" 500 3000 \
  --rpc-url https://robinhood-rpc.publicnode.com

# 3498

cast call SOON \
  "readV4(bytes32)((bool,uint160,int24,uint128,uint24,uint24,uint24,uint24,uint24))" \
  0x3bb34a44f1b2b5f32c034c38a53065a521a47b199700fa9bd19d60985ff24bf1 \
  --rpc-url https://robinhood-rpc.publicnode.com

The executor takes the route KUDARO writes and the floor you are willing to accept. Spending your tokens needs an approval to Permit2 and a Permit2 allowance to the executor: neither is requested by the contract itself, because an allowance is yours to give and a contract that asks for one on your behalf is a contract that can spend it later.

Both were compiled with Coming soon. The router address was not taken from a deployment list: the canonical Universal Router address exists on this chain but its pool manager points at an address with no code, so it is a copy that cannot execute. This one was found by reading which contract the chain’s own swap traffic passes through, and confirmed against its bytecode: the v3 factory, the v4 singleton, Permit2 and the v3 init code hash are all baked into it as immutables.

The published source

Both contracts are verified on the chain’s explorer, so the code that runs can be read beside the bytecode rather than taken from us. The match is partial: the runtime bytecode is identical, and what differs is the metadata hash, which carries build paths rather than logic.

• Coming soon
• Coming soon

These contracts are new and they have not been audited. Code that has not been attacked is not code that is known to be safe, and no amount of testing against live chain state changes that. The executor is the one that touches money, and it is the one to be careful with.

What comes next is an audit, and only then an invitation for anyone else to use it. That order is deliberate, and it is the last item on the roadmap.