Incentive Design and Cross-Chain Rebalancing
Congrats to our client Superset on closing a $4M seed round co-led by 7RIDGE and Exponential Science Capital, with Charles McManus (former ClearBank CEO) joining as Chairman!
Superset is going after stablecoin liquidity fragmentation. When a token lives on multiple chains, its liquidity is split across isolated pools on each. Higher slippage, wasted capital, poor execution versus centralized alternatives. Superset's answer is to virtualize liquidity using a hub-and-spoke architecture: the hub chain runs a Uniswap v3-style vAMM over mirror tokens for global price discovery and swap calculation, while spoke chains hold the real token balances and settle users locally. The system trades like a single deep pool, but settlement stays on-chain where the user is.
Superset's team asked Sentinel to design the protocol's markets layer. The problems are specific to Superset's architecture but versions of them show up in every multi-chain protocol:
How do you keep durable settlement inventory on each spoke when a singleton vault serves every pool on that chain? Uniswap v3 concentrated liquidity already rewards in-range LPs with trading fees. That handles execution. The protocol also needs committed token balances sitting on each spoke to ensure settlement capacity. Incentive accounting has to work per token, per spoke, in a way that resists deposit sniping.
How do you fix inventory drift across chains when flow is asymmetric, without overpaying or creating churn? When one spoke has a surplus and others have deficits, settlement capacity is in the wrong place. A market participant needs to move tokens, and the protocol needs to pay based on how much the move improves the system.
The sections below cover how we solved each of these.
Why Singleton Vaults Change the Incentive Problem
Superset's spokes use a singleton vault model: one contract per chain holds all of a token's balances across every pool on that spoke. So if four virtual pools use USDT0 on a given chain, they all draw from the same USDT0 vault.
This is good for capital efficiency. It de-fragments liquidity within a chain and increases the maximum trade size any user can execute. But it also means you cannot measure an LP's contribution on a per-pool basis. Incentive accounting has to work per token, per spoke, across all pools consuming that token. That constraint drove the Token Pot design.
Inventory Incentives: The Token Pot
Inventory is settlement capacity. The protocol needs durable token balances sitting on each spoke so trades can settle locally, even when LP positions move. Because of the singleton vault design, that inventory serves all pools on the spoke that use the token.
LPs who concentrate positions near the active price already earn trading fees through Uniswap v3's native mechanics. The tighter and more useful your range, the more fees you earn. That handles execution incentives. The Token Pot layers inventory incentives on top. It rewards addresses that commit token balances to a spoke for a full epoch, ensuring the settlement capacity is there when trades need to settle.
Weights use the minimum of an address's balance at t₀ and its balance at t₁.
LP NFTs participate too. The embedded token amounts inside a concentrated position are derived at epoch boundaries from tick range, liquidity, and price snapshots (sqrtPriceX96). Those amounts use the same min(start, end) logic before contributing to the address's weight.
Epochs are 8 hours (aligned with funding cadences used by major venues). Hard locks: stake before t₀, withdraw after t₁. Mid-epoch edits to staked positions are blocked. Dust floors filter spam balances.
Sentinel also designed an additional execution incentive layer called the LP Bonus Pot. It would pay LPs pro-rata to fees earned, adding an explicit execution reward on top of native Uniswap v3 fees. This was deferred from V1 to keep trading fees competitive during the bootstrapping phase, with a clean path to activation as volumes grow.
Permissionless Rebalancing: Pay for Improvement, Not Volume
Even with well-designed incentives, spoke inventory drifts. If users on Chain A are net buying Token 1 and users on Chain B are net buying Token 2, the token ratios diverge from hub-defined targets. Settlement capacity ends up in the wrong place.
Our rebalancing mechanism lets anyone move tokens from surplus spokes to deficit spokes and earn a reward, but only if the move actually makes the system healthier.
All rebalancing is evaluated at a snapshot τ on the hub. The hub tracks raw spoke balances, pending inbound and outbound transfers from prior unsettled commits, and target inventory per spoke. Usable balance incorporates in-flight tokens:
\[
R_i^{\mathrm{usable}}(\tau)
=
R_i(\tau)
-
P_{i,T}^{\mathrm{out}}(\tau)
+
P_{i,T}^{\mathrm{in}}(\tau)
\]
This accounting prevents concurrent rebalancers from racing each other and getting overpaid for the same correction.
Global misallocation is measured as:
\[ M(\tau) = \tfrac{1}{2}\,\sum_i \left| R^{\mathrm{usable}}_i(\tau) - R^*_i(\tau) \right| \]
This is inspired by Earth Mover's Distance: the minimum token mass that must move to align spoke inventories with targets. Rewards are priced per unit of misallocation removed (RPU), not per unit of volume moved. A mass floor prevents the unit price from spiking when imbalances are small, and a per-snapshot budget cap (θ) prevents any single commit from draining the rebalance pot.
Concrete example from the spec: three spokes with targets of 500/250/100 and actuals of 600/200/50. Deviations are +100/−50/−50. M(τ) = 100. Exactly 100 tokens need to move. A rebalancer who moves 60 tokens from the surplus spoke to the 2 deficit spokes earns 60 × RPU(τ), paid in-kind.
Where the Money Comes From
A portion of the fees generated from trading activity on each spoke are routed into budgets for inventory rewards (Token Pot), rebalancing rewards (Rebalance Pot, held at the hub), and a reserve fund (tail-risk buffer for extreme events).
All of these flows are in the traded tokens themselves. No emissions. No points. No subsidy that evaporates post-TGE. Pre-TGE, the entire markets layer runs on realized protocol fees.
Why This Matters Beyond Superset
The problems we solved here show up in every multi-chain protocol: keep settlement inventory where it's needed across chains, fix drift without overpaying, and fund incentives sustainably from fees instead of emissions.
Most projects outsource this to off-the-shelf market maker contracts or skip it entirely. The result is usually inflated circulating supply from poorly structured token loans, lopsided deals, and incentive programs that attract mercenaries and collapse when the subsidy ends.
If you're building a token project and want the markets side (treasury strategy, liquidity growth, deal structuring, incentive design) done with the same rigor you bring to your core engineering, that's what Sentinel does.
→ Superset
→ Tech Funding News coverage of Superset's raise