Procedure

The first instruction the program will ever accept creates the binding account: a storage record keyed by the token contract and the target pool. It stores the pool state key, the bin step, the quote mint, and the vault authorities. Every later instruction re‑derives this record and compares the caller‑supplied pool account against the stored key, so the program can only ever act on one market.

The same instruction enforces the pool’s shape. The quote side must be wrapped ETH. The base side must be the Hatchery mint. The bin step is fixed so that liquidity resolution cannot be renegotiated later, and the fee schedule is left at the pool default because Hatchery’s mechanism never touches fee capture. If any constraint fails, the instruction returns an error and the binding account is never created.

The token contract invokes the program through the transfer‑hook interface on every transfer of the mint. The token program loads the hook permission map, expands it into the instruction, and makes an external call into Hatchery’s execute handler with the source, destination, mint, and the declared extra accounts.

The handler is deliberately cheap. It validates that the accounts resolve to the stored binding, records the transfer in a rolling counter, and returns. It does not move tokens, does not change amounts, and does not fail on ordinary wallet‑to‑wallet transfers. Compute budget matters here: the hook runs inside every transfer, so the work is bounded to a handful of account reads.

When a swap settles against the bound pool, the program reads the post‑swap state: the active bin index, the bin step, and the loaded bin arrays holding liquidity on either side of the active price.

It then walks the bins inside a fixed window around the active bin. Each populated bin contributes its liquidity weighted by inverse distance from the active bin, and the weighted sum is normalized by total pool liquidity. The output is a unitless value between zero and one, written into the coefficient store as a uint256 in nine‑decimal fixed point and emitted as a CoefficientUpdated event.

The walk is bounded on purpose. Bin arrays are large accounts, and every additional array pushes the transaction toward its compute limit. Hatchery caps the window so that the recompute always fits within the budget of an ordinary swap transaction, with no request for extra compute units.

Deposits into the bound pool pass through the program, which rejects positions whose bin span exceeds the allowable width. The width is derived live from the coefficient: max_allowable_bins = MAX_BIN_SPAN × (1 − coefficient).

At coefficient zero, any span is accepted. Near coefficient one, only positions within a single bin step of the active bin survive validation. Rejection is hard, not advisory: the instruction returns HatcheryError::SpanExceedsAllowable, and Robinhood Chain’s atomic execution unwinds the entire transaction, token transfers included.

Withdrawals are always permitted. The program computes how much of the coefficient is released when a position is removed, rather than blocking the exit.

Positions clustered around the active bin release less coefficient than wide bands do. The program reads the position’s bin range, computes its average distance from the active bin, and weights the release inversely. Far liquidity contributed little, so removing it costs little; liquidity sitting on the active bin contributed the most, so removing it is the only way to meaningfully relax the geometry. The result is hysteresis: the pool concentrates easily and dilutes slowly.