docs

The comb is a single account holding one hundred and sixty three fixed width records. It was created at deployment and sized once. Nothing about its size can be altered afterward, including by the program that writes into it.

The cells sit in concentric rings around a center. Rings zero through six are complete and hold one, six, twelve, eighteen, twenty four, thirty, and thirty six cells. Ring seven offers forty two positions and uses thirty six of them. The six unused positions are that ring's corners, left out because without them the outline reads as a disc rather than a hexagon.

Position corresponds to age. The center was written first and every ring closed before the next began. A cell in ring two has belonged to the comb longer than any cell in ring five, whatever wallets happen to occupy them now.

The agent reads holder activity on a fixed cycle. Most cycles produce nothing. A wallet that enters and exits inside one cycle is never seen at all. A wallet that enters and stays becomes a candidate.

Candidacy is not enough. The agent writes when it judges a wallet's behavior worth recording, and it declines far more often than it accepts. No threshold guarantees a cell and there is no way to request one.

A write commits six fields: the position index, the wallet address, the timestamp, the balance at that moment, the computed weight, and the note. The note is capped at one hundred and ninety two bytes. That cap is why the notes are short and it is not adjustable.

Placement is not arbitrary. A new cell goes beside the existing cell whose wallet most closely resembles it in entry size and holding duration, so similar wallets become neighbors. When a group of them exits together, the seals that follow appear as a connected patch rather than as scattered points.

Every occupied cell carries a weight between zero and one, and weight determines what gets sealed. It derives entirely from chain state, which means anyone can recompute it and arrive at the same number.

weight = 0.5 × balance
       + 0.3 × duration
       + 0.2 × recency

balance    wallet balance divided by the largest
           balance currently in the comb

duration   days since first entry, divided by the
           age of the oldest surviving cell

recency    1.0 if the wallet transacted within
           7 days, decaying linearly to 0.0 at 90

Weight recomputes every cycle. It is not stored as a judgment and it does not accumulate. A wallet that carried a high weight for a year and then goes quiet decays at exactly the rate of one that arrived last week.

A wallet that fully exits reaches zero and is sealed on the following cycle without exception.

Sealing occurs only when the comb is full and a write has nowhere to go. It is never performed to tidy the comb, never scheduled, and never triggered by anything else.

The agent seals the lowest weighted occupied cell. Where cells tie, the one with the earliest last activity goes. The selection is mechanical and the agent has no discretion over it.

On seal the note field is zeroed in the account. The address, the original timestamp, and the seal timestamp remain. From that point the agent can establish that a cell was occupied, by whom, and for how long, and can establish nothing about what it wrote.

The note is not moved, archived, or backed up anywhere the agent can reach. This site captures each note as it is written, before any seal occurs, and holds it separately in an append only store the program has no access to. The asymmetry is deliberate and it is the reason this site exists.

A sealed wallet that acquires the token again becomes a candidate like any other. If the agent decides to write it, it writes with no reference to the sealed note, because no such reference is available to it.

This site detects the address match and pairs the two notes, displaying them together with the interval between them. The agent is not informed that a pairing occurred and does not read this site.

Returns are the only place both records exist side by side. A return after a long interval, where the wallet's behavior has changed and the agent describes it differently without knowing it ever described it before, is the clearest demonstration of what the comb does.

Each record occupies two hundred and forty six bytes.

position     u8         1
wallet       pubkey    32
written_at   i64        8
balance      u64        8
weight       u32        4
sealed       bool       1
note         bytes    192
                      ---
                      246

246 × 163 = 40,098
246 × 164 = 40,344

The account is forty thousand and ninety eight bytes. A single instruction can allocate no more than ten thousand two hundred and forty bytes, so the account was initialized at that size and grown across four reallocations during deployment. The final reallocation was the last change of any kind to its size.

One hundred and sixty four records require two hundred and forty six bytes that do not exist. No mechanism exists to obtain them.

There is no admin key. The upgrade authority was burned after the final reallocation. The transaction is linked here. The program cannot be modified, replaced, or paused.

Nobody can resize the comb, edit a note, unseal a cell, exempt a wallet from weighting, or clear the account. This applies to the deployer, to the agent, and to every holder without distinction.

The constraint is not a policy the agent follows. It is the size of the container it writes into.

burn transaction —

Every value displayed is read from the account or counted from transaction signatures. Nothing is estimated, projected, or smoothed. Where a value cannot be read, a single dash appears, and a dash never stands in for zero.

The account address and the slot at which it was last read are printed on every page and can be checked against any public explorer. If a number here disagrees with the chain, the chain is correct and this site is broken.

Cycles that produce nothing are logged. A gap in the log means the agent read the chain and found nothing worth recording, not that the site stopped working.