Address-cluster proximity with no cluster index
You are looking at Bitcoin value-flowpacked address behavioural containers in one Semurg substrate. Ask it to find addresses within a proximity band, no cluster index and it runs the
real query live on this box, on data you can
download and re-run yourself ▸.
Click an example in the agent rail, or change the proximity band, e.g. within proximity 50 or near a seed address. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
Every Bitcoin address is one packed behavioural container on disk. An address-cluster proximity query is a flat SIMD sweep of those packed containers, fanned across every core. No cluster index to build, no second system. Total time, measured live.
the graph-DB leader
BUILD THE INDEX FIRST. A graph database must load the addresses and build a cluster or adjacency index before it can answer the first proximity query, a second structure to maintain forever.
semurg, one engine
Zero indexes built. A proximity query is a flat SIMD sweep of packed address containers fanned across every core, so it answers the instant the addresses land, no index, no second system.
The whole cluster index, and the system that holds it, is gone.
The live Bitcoin value-flow graph. Measured live on this box. Re-pull it over Bitcoin P2P and re-run it yourself.
ask the agent for addresses "within proximity 25", the live container sweep renders here
Honest split: the cold first sweep is disk-bound (io_uring bandwidth over the container region); the warm resident sweep is the steady-state proximity-filter rate, shown side by side, never our-hot against their-cold. The proximity predicate is a flat test over each packed address container, so this is the real cluster-proximity rate. The structural win is COLLAPSE: no cluster index to build, no load step, no second system. The query answers the instant the addresses land, and the same engine also serves graph, full-text and vectors in one pass, durable on disk.