Components behind a Silo market
Silo is a discrete-bin liquidity market maker implemented as a Uniswap v4 hook, the first DLMM built this way. The v4 singleton PoolManager owns settlement, flash accounting, and pool bookkeeping; Silo's hook contract owns everything that makes a market dynamic: bin placement, the active bin, fee behavior, and reference-price checks. The differentiating work is making that dynamic liquidity understand tokenized assets, external prices, market conditions, NAV, and real-world settlement constraints.
The Uniswap v4 singleton: settlement, flash accounting, and pool registry.
Runs each market's discrete bins and executes bin-based swaps inside v4 callbacks.
Find execution paths and preview results.
Tracks ownership, bins, composition, and fees.
Sets the fee per swap from market and risk parameters, via the hook.
Validates external price or NAV inputs before the hook accepts them.
Identifies canonical assets for the interface.
Aggregates swaps, liquidity, fees, and positions.
The division of responsibility in that list is deliberate rather than incidental. Everything on the Uniswap side is infrastructure Silo consumes: settlement, accounting, and the callback surface v4 provides to every pool built on it. Everything on the Silo side is the protocol's own, and it is where both its behavior and its risk live. A bug in the singleton would be a Uniswap problem affecting many protocols. A bug in bin placement or fee logic is a Silo problem, and keeping that surface small is the point of the arrangement.
Why a hook rather than a standalone contract
The bin model could be built as an independent AMM. Implementing it as a Uniswap v4 hook trades some freedom for properties that matter more for a market meant to be traded through by other software.
The cost is that the hook operates inside the callbacks v4 provides, and its behavior is bounded by what the singleton permits. That constraint is deliberate. The parts of the system most likely to hold a bug are the parts Silo writes, and keeping them small is a design goal rather than an accident.
The routing argument is the easiest of the four to underestimate. A market no aggregator can reach depends entirely on traders arriving through its own interface, which puts it in competition for attention rather than for execution quality. Being reachable through infrastructure that already exists lets a Silo market compete on the thing it is actually good at, which is the price it can offer for a given size.
Stock Token integration principles
When a market uses Robinhood Stock Tokens, the canonical ERC-20 contract is the pool asset. Robinhood or RHJ handles issuance. Silo supplies secondary-market liquidity infrastructure around the token. An implementation should use canonical addresses, relevant reference data, and correct corporate-action or multiplier behavior without implying rights that the token itself does not provide.
The path of a swap
A swap moves through the v4 singleton and into Silo's hook, which owns everything specific to the bin model.
- 1Router quotes the trade
The execution path and expected output are previewed before anything is submitted.
- 2PoolManager takes the call
The v4 singleton handles settlement and flash accounting for the swap.
- 3The hook prices it
Silo's hook determines the fee, walks the discrete bins, and produces the fill.
- 4Reference checks apply
Risk controls can restrict execution when external data is unusable.
- 5Accounting updates
Bin inventory, position composition, and accrued fees are updated for the affected LPs.
Step three is where the design earns its complexity. Walking bins is more work than evaluating a curve, because the hook has to determine how much of the trade each price level can absorb, apply the fee, and update inventory at every level it consumes. In exchange, the fill it produces is exact rather than approximate: each portion of the trade executed at a specific known price rather than somewhere along a continuous function.
Flash accounting in practice
The v4 singleton does not move tokens at every step of a swap. It tracks what is owed, lets the operations in a transaction net against each other, and requires the balance to be settled before the transaction ends. For a bin-based market this matters, because one trade may touch many bins.
- During the swapThe hook walks bins and accumulates deltas rather than transferring tokens at each level.
- Across a routeA trade passing through several pools nets its intermediate legs instead of settling each one separately.
- At the endThe transaction must leave no outstanding balance, which is what makes the netting safe.
Without this, a bin-crossing trade would be prohibitively expensive. Every level consumed would mean its own token transfers, and a trade crossing a dozen bins would pay for a dozen settlements. Netting them into one is what makes the discrete-bin model viable onchain, and it is a large part of why building on v4 was an enabling decision rather than merely a convenient one.
What lives in the hook
The split matters: the singleton is shared infrastructure, and everything that makes a Silo market dynamic is Silo's own code.
The data path
Contracts hold the authoritative state, but very little of what an interface shows can be read directly from them at acceptable cost. Analytics comes from indexing the events those contracts emit.
The distinction matters for correctness as much as for performance. A figure read from contract state is current by definition, an indexed figure is only as fresh as the indexer, and a derived figure carries the assumptions of whoever computed it. Metrics and analytics covers how those differences should be presented.
It is also why an interface should never present an indexed figure and a contract-read figure with the same visual weight and no distinction. A position's accrued fees can be read from state and are exact. A pool's 24-hour volume comes from an indexer and is correct as of its last processed block. Showing both as plain numbers implies a confidence in the second that it does not have.