docs
plumbing.
this page covers how wilk actually reads the chain, not what it means when it finds something. that part is on /about. this part is plumbing.
how a pool gets read
every venue gets read the same way. that is the part worth stating plainly. it would be faster to hit each dex's own api and let them hand back a price, but that means trusting each one to report the same kind of number the same way, and there is no guarantee of that. reading the reserve accounts directly means every pool, on every venue, gets treated identically. the price is derived the same way every time, regardless of which venue it came from. that consistency is the only thing that makes a spread between two venues mean anything. if the two sides were priced differently in method as well as market, the comparison would not be worth making.
how the sample rotates
wilk does not hold a fixed list of pools it checks every cycle. the pool universe on solana is large and changes constantly, new pools appear, old ones go quiet, and a fixed list would go stale the moment it was written. instead each cycle draws a fresh sample from the pools currently available across the covered venues. which pools land in a given cycle is not fixed and not something logged in advance. you only find out what was checked by reading the entry after the cycle runs.
this has a consequence worth naming. wilk cannot promise it checked every possible overlap. it promises it kept checking, continuously, without ever deciding in advance what was worth looking at. those are different guarantees. the second one is the one being made here.
what a match actually requires
a pair counts as a match when the same two tokens are paired against each other in a pool on more than one covered venue, within the same cycle. a token existing on multiple venues is not enough on its own, since it might only be paired against different assets on each one. the pairing itself has to match, not just the token.
why fees and slippage gate the viable flag
a spread that looks large on paper can still cost more to act on than it is worth. the viable flag runs a plain check, the size of the spread against an estimate of what it would cost in fees and slippage to move through both pools. this number is a threshold check, not a profitability guarantee. actual cost depends on trade size, current liquidity depth, and network conditions at the moment of execution, none of which are fixed inputs here. viable means the gap clears a baseline. it does not mean acting on it is free of risk.
what counts as a failed read and why it is not retried
a read fails when a pool does not respond before the cycle needs to move on, or when the data that comes back cannot be parsed into a usable price. when that happens the cycle is logged as a gap and wilk moves to the next pool in the sample. it does not go back and try again.
the reason is simple enough to state directly. a retry is a place where a bad result can quietly be replaced with a better looking one. once that mechanism exists, even used carefully, there is no way for anyone reading the log to tell a genuine first-try result from a cleaned up one. removing retries removes that question entirely. a gap means exactly what it says, this pool did not answer, and nothing after the fact changes that.
terms used in the log
these are not official definitions handed down from anywhere. they are just the words used consistently across the site and the log, written down here so they mean the same thing every time they appear.
