Build the liquidity layer in stages

Silo's product direction moves from liquid tokenized-asset markets, to automated strategies on top of them, to infrastructure built for the settlement behavior of specific real-world assets. Each stage widens what the protocol can support without changing the market structure underneath it.

The three stages are ordered by dependency rather than by ambition. V1 concerns market structure: whether discrete bins and dynamic fees support a usable market in an asset whose price lives partly off-chain. V2 assumes that structure and addresses the effort of maintaining a position, which is the main reason LPs stop supplying a market they otherwise like. V3 addresses assets whose settlement behavior the first two stages deliberately kept out of scope.

How stages are ordered

Stages describe sequence rather than schedule. The ordering reflects what each stage requires from the one before it, which is why an item can be well understood and still sit in a later stage.

The distinction between sequence and schedule is not a formality. An item's position in this list says what has to be true before building it becomes sensible, not when anyone expects to have built it. Reference-relative rebalancing is a good example: the mechanism is straightforward, and what it waits on is confidence in the reference data it would move positions against.

Read in that order, the stages describe a widening scope rather than a series of rewrites. Nothing in V2 or V3 changes what a bin is, how a position is composed, or how fees accrue. They add automation above that structure and specialization around it, which is why an LP who understands the core model understands every stage.

What each stage depends on

The stages are ordered because later work depends on earlier work being correct, not only because it is scheduled after it. Each one rests on something the previous stage has to establish.

An item can therefore be well understood and still be far away, because what it waits on is evidence rather than engineering time.

Why the order is what it is

Each stage removes a different constraint. V1 addresses market structure, which is the constraint on whether a tokenized asset can be traded well at all. V2 addresses the effort of holding a position, which is the main reason LPs leave a market they otherwise like. V3 addresses assets whose settlement behavior the first two stages deliberately kept out of scope, because NAV schedules and redemption windows change what a market has to do rather than only how well it does it.

How a stage is considered complete

Availability labels elsewhere in these docs are the authority on what exists. This is the standard those labels are applied against.

• ImplementedThe behavior exists in deployed contracts, not only in a specification or a test environment.
• MeasuredIt has run against real activity, and the numbers describing it come from that activity.
• DisclosedThe interface shows what it does, including the cases where it restricts or refuses an action.
• DocumentedThese pages describe the behavior as built, and the availability label has been changed to match.

All four are held to together, because a capability that satisfies three of them is the one most likely to be misread. Something that runs correctly but is not documented, or is documented but has not been measured against real activity, is not finished in the sense that matters to anyone depositing into it.

What the core model covers

The core model is the part that does not change between stages: discrete bins, concentrated and single-sided positions, the liquidity shapes built on them, the v4 hook that runs the market, dynamic fees, and the reference-price controls that sit around execution. Everything in V2 and V3 is built on that structure rather than replacing it, which is why the market model described in these pages holds regardless of which stage a given capability arrived in.