docs
what this is
silas is a machine that walks because people trade. the unit is a six legged rack, a body account on solana, a token with a transfer hook that reports every movement of the token into the body. there is no operator. there is no schedule. the body changes only when a transfer lands or when a rule that a transfer tripped fires. if nobody trades, silas stands still and the readings on this site do not move, because there is nothing to move them.
the enclosure page shows the unit from the outside. the panels in the side bars are the gauges bolted to the rack. each gauge is a direct read of a field on the body account or a value computed from those fields in the browser with the exact formula written on this page. nothing on the site is estimated and nothing is simulated. if a value is blank the account that holds it does not exist yet or has not been configured.
the hook
the mint is a token extensions mint with the transfer hook extension enabled. every transfer of the token calls the silas program with the source, destination, amount and the accounts the hook needs. the program never blocks a transfer. it reads the transfer, updates the body, and returns. the program is the only writer to the body account. no instruction on the program takes a signer other than the hook path itself, which is invoked by the token program.
because every transfer passes through the hook, the program sees buys and sells from the pool as transfers between the pool's token account and a holder, and sees holder to holder movement as transfers between two wallets. direction is decided by which side is the pool. a transfer where the pool is the source is a buy. a transfer where the pool is the destination is a sell. anything else is a move.
bands and legs
the body keeps six balance bands. the edges between bands are six integers read from the genome. a holder's band is the highest band whose lower edge is at or below the holder's balance. each band is carried by one leg. the leg stores the total balance in its band, which this site calls load, and the number of holders in it, which this site calls bearing. on every transfer the program adjusts the load and bearing of the legs the source and destination belong to, before and after the transfer, so a holder moving from one band to another leaves one leg and joins the other.
a leg has a bearing floor read from the genome. when a leg's bearing falls below its floor the leg is faulted. a faulted leg damages the hull on every transfer until its bearing climbs back above the floor. three faulted legs at once is not itself a scrap condition, but the hull damage from three faulted legs is severe enough that a scrap usually follows unless buys repair it.
steps, shuffles and strides
a step is a transfer that moves either the source or the destination across a band edge. a shuffle is a transfer that moves neither. the body counts both. each step swaps the grounded tripod, a single bit on the body, and increments the odometer by one. the odometer is the total number of steps the unit has taken in its life. it only goes up.
every one thousand and twenty four steps the body enters a stride event. the stride event does three things in order. it seals a platter on each of the six legs, which is a small record of that leg's load, bearing and the odometer value. it repairs the hull by the genome's repair per stride amount. it runs the cargo rule, which is described below. stride events are the only moments platters are written, so the history of the unit is sampled by distance walked, not by time.
the map
the unit has a position on a hexagonal grid stored as two integers and a heading stored as a number from zero to five. each step moves the unit one cell in its heading. before the move, the program looks at the net direction of volume since the last step. if net volume is a buy the heading is kept. if net volume is a sell the heading turns one sixth of a turn clockwise. the path is therefore drawn by the market. a long run of buys is a straight line. a sell heavy stretch is a tightening spiral.
the map page draws every cell the unit has ever stood on as a line plate, with the step number printed at each stride event. the body account does not store the whole path; it stores the current position, heading, and a count of distinct cells visited. the path is reconstructed in the browser from the sealed platters and the heading changes written into the fault log on pip, which records every heading change with its odometer value.
power
each step costs a fixed amount of token from the power cell, a balance held by the body. the cell is refilled from a share of the hook fee on every buy. when the cell cannot pay for a step, the step is refused and the band crossing that caused it is queued on the body in order. while anything is queued the unit is stalled, the face shows starved, and the odometer does not move. the next buy that refills the cell drains the queue as ordinary steps, in order, until the cell is empty again or the queue is empty. a stall is logged on pip with the number of transfers it lasted.
antennae
the two antennae are integrators. antenna a adds the token amount of every buy and subtracts the token amount of every sell. antenna b adds one for every destination wallet that had a zero balance before the transfer and subtracts one for every source wallet that has a zero balance after it. after each transfer, both integrators are multiplied by their decay rates, two numbers from the genome below one, so the signal fades with activity rather than with time. a quiet market leaves the antennae exactly where they were.
each antenna has a threshold from the genome. when the absolute value of both integrators is above threshold and both have the same sign, the unit locks. a lock fires one buyback from the fee reserve sized to the smaller of the two absolute gains, capped at the reserve balance, and then both integrators are set to zero. when both are above threshold with opposite signs, the unit faults: the hull takes the fault damage amount and both integrators are halved. a lock or a fault is written to pip's log with the odometer value.
hull and scrap
the hull is a number from zero to the genome's hull maximum. it is reduced by sells whose amount is larger than the damage fraction of the smallest leg's load, by antenna faults, and by every transfer that happens while any leg is below its bearing floor. it is increased by buys whose amount is larger than the same fraction and by the repair amount at every stride event. the enclosure page shows the hull as a percentage of its maximum.
when the hull reaches zero the skull plate rule fires in the same transaction. the fee reserve and the power cell are burned. a final platter is sealed on every leg with a scrapped flag. the genome, the position, the heading, the odometer and the face bitmap are copied onto pip. the body's state field is set to scrapped and the hook enters a dead mode in which it still returns success on every transfer but writes nothing. pip's survival count is incremented. the successor, if one is created, is a new mint whose body is initialized from pip's stored genome rather than from a fresh one, so the lineage carries the mutations forward.
heat and venting
heat is a running sum of the hook fee on sells since the last vent. it is stored on the body as a token amount. the vent threshold is a genome value. when a sell pushes heat at or above the threshold, the program burns the heat amount from the fee reserve in the same transaction and resets heat to zero. the enclosure draws heat as sixteen slats per side, each slat a sixteenth of the threshold. venting and the antenna buyback are separate rules with separate triggers and can both fire on the same transfer.
cargo
at each stride event the fee reserve is split three ways by the cargo split from the genome, three bytes that are normalized to sum to one. the buyback share purchases token from the pool and burns it. the burn share is burned directly. the cargo share is moved into a crate account and counted as a crate on the unit's back. at the following stride event the oldest crate is unloaded: the program finds the leg with the lowest load relative to the mean load of all six and distributes the crate's contents to every holder in that band in proportion to their balance. the unit balances itself. a market that leaves one band thin gets that band fed.
the genome
the genome is two hundred and fifty six bytes on the body, viewed as thirty two slots of eight bytes. on every transfer the program takes the first eight bytes of the transaction signature and xors them into the slot at index amount modulo thirty two. the genome is never read raw. each parameter is a byte or a pair of bytes mapped into a fixed safe range, listed on the genome page, so no mutation can set a threshold to zero, a decay to one, or a band edge below the previous band. the unit drifts. it does not break.
pip
pip is a second account derived from the mint. it holds a ring of the last sixty four face bitmaps, a copy of the genome taken at the last stride, a copy of the position and heading, the survival count, and a log of faults, locks, vents, stalls and heading changes, each tagged with the odometer value. pip is written by the body on those events and is the only account that survives a scrap. the pip page shows all of it.
reading this site
every value on the enclosure page is either a field on the body or pip, or one of these formulas. mass is the unit price from the pool times the total supply of the mint. hull percent is hull divided by hull maximum. steps to next stride is one thousand and twenty four minus the odometer modulo one thousand and twenty four. lit slats is heat divided by the vent threshold times sixteen, rounded down. the chart in the top strip is the mass sampled once per second since the page opened, seeded with the last six hours of one minute closes. nothing else is computed and nothing is guessed.