Steamm

November 2024
Nope 0xxgen Ripleys
nope@solend.fi 0xxgen@solend.fi ripleys@solend.fi

ABSTRACT corresponding bToken is pegged one to one with the respective

Steamm is an Automated Market Maker with an embedded money underlying.
market integration, designed to maximize capital efficiency. It fea-
tures a composable architecture that allows for the integration of
various quotation system, such as a Constant-Product quoter, quot-
2 BANK
ers specialized in stablecoin trading, as well as dynamic fee quoters Banks operate by pooling liquidity from a given coin type and
based on market volatility and trading volume. allocating a portion of that liquidity to lending markets, thereby
Steamm’s liquidity re-utilization model deposits idle liquidity earning yield. By consolidating liquidity, AMM pools can fulfill
into Suilend’s lending markets, improving capital efficiency and their swap commitments by tapping into the global net liquidity
generating additional yield for liquidity providers. available in the respective banks, thereby reducing the liquidity
recall frequency from lending markets.
For example, if one pool experiences high demand for SUI (i.e, a
1 INTRODUCTION high volume of swaps extracting SUI from the pool) and another
Traditional AMMs often keep liquidity idle, earning yield only when experiences high supply of SUI (i.e., a high volume of swaps adding
actively used for trades. This results in a significant opportunity cost SUI to the pool), these flows will largely offset each other.
for Liquidity Providers (LPs). Steamm addresses this inefficiency In other words, during periods of low market correlation, off-
by introducing a shared liquidity model, allowing unused funds to setting flows occur. However, during periods of high market corre-
generate yield in lending markets while remaining accessible for lation, there is a greater need to recall liquidity from the lending
trades. markets.
The protocol’s modular quotation design enables seamless inte-
gration of various swap quotation systems. This flexibility accom-
2.1 Yield-bearing LP tokens
modates innovation, allowing new quotation models to be added as
the DeFi industry evolves. With these features, we combine adapt- Liquidity re-utilization not only enhances overall market efficiency
ability and efficiency, offering LPs enhanced earning opportunities but also allows liquidity providers to earn a money-market yield
and bespoke solutions for traders. on their funds while market-making. Banks deposit funds into
In its core, the protocol operates on the following objects: the lending market, earning a yield 𝑟 , that compounds over time.
They then act as pass-through entities, distributing the yield to the
• Pool<A, B, Quoter, LendingMarket>: Top-level object and respective pools in proportion to the time and principal invested.
sits at the core of the protocol. The generic types A and B The bank facilitates this pass-through process by allocating an
correspond to the associated coin types of the AMM. The intermediate bToken to each participating pool. Whenever a pool
Quoter type corresponds to the type of the associated quote adds new funds to a bank, the bank issues bTokens in proportion
module. The Quoter also stores state. The pool object holds to the new incoming principal relative to the bank’s current value
information related to the pool’s liquidity, trading data, (taking into account both funds on Suilend and funds held in con-
protocol and pool fees, LP Supply, bToken balances as well tingency).
as the inner state of the quotation model.
• Bank<LendingMarket, T>: This object sits between the AMM
pools and the lending markets. The Bank aggregates all
Δ𝑃𝑟𝑖𝑛𝑐𝑖𝑝𝑎𝑙 ∗ 𝐵𝑠𝑢𝑝𝑝𝑙 𝑦
funds of type Coin<T> from all corresponding pools. It also Δ𝐵𝑡𝑜𝑘𝑒𝑛𝑠 = (2.1)
manages the relationship between the types Coin<T> and 𝑃𝑟𝑖𝑛𝑐𝑖𝑝𝑎𝑙 + 𝐼𝑛𝑡𝑒𝑟𝑒𝑠𝑡
Coin<BToken<T».
Note that the pool holds bTokens and handle swaps through them. In a nutshell, bTokens enable the interest earned to flow back into
By holding bTokens, Pools will accrue interest accumulated from the pool, where it is added to the liquidity and distributed further to
the bank’s lending operations, interest which is then distributed to each LP position. In practice, the effective yield generated on funds
LPs, throughout the LP redemption process. allocated to a bank is lower than the lending market yield, as the
Not all coin types will have a liquid lending market. In such bank maintains a utilization rate below 100% to ensure pools can
cases, the bank will not deploy them to the money markets and fulfill trades without having to withdraw funds from the lending
instead will keep the full amount in custody. For such cases, the market.
1
 Adams et al.

In the same way, when flows are positive we deploy funds to the
lending market if the following condition is met:

𝑈 > 𝑈∗ +𝑏
𝑑
⇐⇒ > 𝑈∗ +𝑏
𝑎 + 𝑑 + Δ𝐿
Figure 1: End-to-end flow from LP tokens, to bTokens to ⇐⇒ 𝑑 > (𝑈 ∗ + 𝑏)(𝑎 + 𝑑 + Δ𝐿) (2.2.4)
cTokens
Where the deploy amount Δ𝑑 is computed as follows:

2.2 Utilization Target and Buffer 𝑑 + Δ𝑑

Banks are configured with a target utilization rate. Liquidity de- = 𝑈∗
𝑎 + 𝑑 + Δ𝐿
ployed to the lending market is allowed to fluctuate around the ⇐⇒ Δ𝑑 = 𝑈 ∗ (𝑎 + 𝑑 + Δ𝐿) − 𝑑 (2.2.5)
target utilization rate and the extent to which these fluctuations
can deviate from the target is defined by a utilization buffer. So if The ability to parameterize utilization allows the protocol to max-
the target utilization is set at 50% with a utilization buffer of 5%, imize efficiency without compromising on market-making. When
then utilized liquidity is allowed to fluctuate between 45% and 55%. market conditions indicate unidirectional volatility, banks can ad-
just the utilization rate higher or lower, depending on which side
of the trading pair is experiencing sell pressure. Conversely, when
volatility is relatively symmetric, the utilization rate can be lowered
to account for bidirectional flows.

3 SWAP MODEL
Given the yielding nature of the liquidity, swap quotations are
applied to the bToken counterparts of each token. This approach
allows pools to consider the accumulated interest of each asset as
part of the liquidity itself. In practice, when a user swaps, say, USDC
for SUI, the protocol first converts the input amount of USDC into
an equivalent amount of BUSDC, then quotes the output amount in
BSUI, which is ultimately converted into the corresponding amount
Figure 2: Illustration of utilization range
in SUI.
Since a swap consists of an inflow and a corresponding outflow, a
These parameters are set by the global admin when lending is
provisioning action optionally occurs prior to the swap execution to
initialized. However, they can be updated dynamically, enabling
ensure the bank has sufficient funds to fulfill the outflow. A follow-
strategies that manage utilization based on market conditions such
up action then rebalances the liquidity from the inflow, maintaining
as volatility and order flow.
the bank’s equilibrium.
The utilization rate 𝑈 is defined as ratio between deployed liq-
uidity 𝑑 and total liquidity 𝐿 (deployed plus available liquidity 𝑎):

𝑑
𝑈 = (2.2.1)
𝐿
where 𝐿 = 𝑑 + 𝑎
When a given inflow or outflow Δ𝐿 occurs, we recompute the
post utilization rate, such that for negative flows we recall funds
from the lending market if the following condition is met:

𝑈 < 𝑈∗ −𝑏 Figure 3: Illustration of a swap flow

𝑑
⇐⇒ < 𝑈∗ −𝑏
𝑎 + 𝑑 − Δ𝐿
⇐⇒ 𝑑 < (𝑈 ∗ − 𝑏)(𝑎 + 𝑑 − Δ𝐿) : Δ𝐿 < 𝑎 + 𝑑 (2.2.2) The swap model can be broken down into two functional parts:
The execution of the swap using bTokens and the conversions
Where 𝑏 stands for the utilization buffer. between the bToken and the underlying.
The recall amount Δ𝑎 is then computed as follows: Given that a swap has both an input and an output, the bToken
logic wraps around the swap execution logic. For a buy SUI / sell
𝑑 − Δ𝑎 USDC trade, the flow is as follows:
= 𝑈∗
𝑎 + 𝑑 − Δ𝐿 • Mint bUSDC by adding USDC to the bank via
⇐⇒ Δ𝑎 = 𝑑 − 𝑈 ∗ (𝑎 + 𝑑 − Δ𝐿) (2.2.3) bank::mint_btoken()
2
Steamm

• Execute swap: The pool executes the swap on the bTokens, preserving the product of the reserves of the two assets in the pool,
via quoter_x::swap() and returns bSUI as the output ensuring that the product remains constant regardless of the trades
• Burn bSUI in return for SUI via bank::burn_btoken() that occur.
• Rebalance the utilization of the bSUI and bUSDC banks We define the constant-product formula as:
if the utilization rates fall below or above the utilization
thresholds
𝑥 (𝑦 + 𝑐) = 𝑘 (5.1)
4 LIQUIDITY PROVIDERS Where 𝑥 represents the reserve of asset 𝑋 , 𝑦 the reserve of asset 𝑌 ,
With regard to the deposit and withdrawal of liquidity by the LPs, 𝑐 being a vertical offset, and 𝑘 the invariant product of the reserves.
the flow is rather straightforward. When a trader swaps one asset for another, the constant-product
When depositing liquidity, the respective banks will optionally formula is adjusted to reflect the new reserves while maintaining
deploy extra liquidity to the lending markets to guarantee that the invariant 𝑘.
utilization bounds are met. Given a swap, the AMM adjusts the reserves to maintain the
invariant.
Given an input Δ𝑥, the pool will return an output Δ𝑦 such that:

𝑘
𝑦 − Δ𝑦 + 𝑐 = (5.2)
𝑥 + Δ𝑥
Hence:

Figure 4: Illustration of a deposit 𝑘

Δ𝑦 = (𝑦 + 𝑐) − (5.3)
𝑥 + Δ𝑥
By contrast, when redeeming liquidity, we check if the outflows Fees are then computed on the output amount Δ𝑦:
can be met and if the banks utilization remains within the bounds
defined, and if not the banks will recall the required liquidity from
the lending markets. Fee = Δ𝑦 × 𝐹𝑒𝑒𝑅𝑎𝑡𝑒 (5.4)
As for the offset, it allows pool creators to initialize a pool with
one-sided liquidity. By setting the offset as a non-zero value we are
shifting the constant-product curve vertically.
We can therefore define the point at which the curve intercepts
the x axis (when 𝑦 = 0) as follows:

Figure 5: Illustration of a withdraw 𝑥 (0 + 𝑐) = 𝑘

⇐⇒ 𝑥𝑐 = 𝑘
5 QUOTERS ⇐⇒ 𝑥 = 𝑘/𝑐
Currently, the protocol has three built-in quotation models: a Constant- (5.5)
Product Quoter, a Stable Quoter, and a volatility-based dynamic-fee
Quoter. 5.2 Stable Quoter
To initiate a pool, the base pool module provides a generator func- The Stable Quoter provides a constant price formula for the purpose
tion pool::new(), for use by the quoter modules to construct the of trading stable coins. This quoter provides a quotation for trading
pool. This function allows each quoter to integrate its custom state. stables in a fixed range of reserve ratios, defined by the pool. We
The quoter then export in its public interface quoter_x::new(). defined the lower reserve ratio bound 𝑅𝑙 and upper reserve ratio
Similarly, the base module makes the core swap function bound 𝑅𝑢 as follows:
pool::swap() available to the quoters, which are then responsible
for re-exporting the swap functionality in its public interface, via 𝑥
quoter_x::intent_swap(), quoter_x::execute_swap() and 𝑅𝑙 = 𝑙 (5.2.1)
𝑦𝑙
quoter_x::swap(), the latter wrapping both the intent and the
execution in one function call. Representing the lower bound of the ratio between token 𝑋 and
This design allows quoters to define a logic before and after the token 𝑌 beyond which the pool no longer offers a quotation.
execution of the main logic defined by the pool module.
𝑥𝑢
𝑅𝑢 = (5.2.2)
5.1 Constant Product Quoter 𝑦𝑢
The constant-product quoter uses the default constant-product Representing the upper bound of the ratio between token 𝑋 and
function with an offset. This quoter operates on the principle of token 𝑌 beyond which the pool no longer offers a quotation.
3
 Adams et al.

5.3 Dynamic Fee Quoter pools, creating extra value for LPs while preserving enough reserve
The Dynamic Fee Quoter provides a quotation mechanism with liquidity for active trading.
dynamic fees based on market volatility. When a trader swaps, the This modular, yield-enhancing design makes Steamm a power-
quoter computes an exponential-moving average of the volatility ful protocol for liquidity providers, offering both market-making
based on a reference price and accumulated volatility metric. functionality and improved yield with lower opportunity cost. By
We use absolute price deviations as a proxy for volatility. We balancing reserve availability and yield generation, Steamm ensures
define the accumulated volatility metric as follows: an optimized experience for users in the Sui ecosystem, meeting
both trading and investment needs efficiently.
 
𝑉𝜆 = max 𝑉ˆ + max(|𝑃𝑜𝑟𝑎𝑐𝑙𝑒 − 𝑃ˆ |, |𝑃𝑖𝑛𝑡𝑒𝑟𝑛𝑎𝑙 − 𝑃ˆ |), MaxVol
(5.3.1)
Where 𝑃𝑜𝑟𝑎𝑐𝑙𝑒 stands for the oracle price and 𝑃𝑖𝑛𝑡𝑒𝑟𝑛𝑎𝑙 the inter-
nal constant-product price of the pool. The volatility accumulated
metric is capped by a parameter 𝑀𝑎𝑥𝑉 𝑜𝑙 defined by the pool.
When a swap occurs, at 𝑛 + 1, we compute the reference price
as well as the reference volatility:

,𝑡 =0

 𝑃
 𝑜𝑟𝑎𝑐𝑙𝑒


𝑃ˆ𝑛+1 = 𝑃ˆ𝑛

, Δ𝑡 < 𝑓 (5.3.2)

, Δ𝑡 ≥ 𝑓

𝑃𝑜𝑟𝑎𝑐𝑙𝑒





 0 ,𝑡 =0
𝑉ˆ𝑛 , Δ𝑡 < 𝑓


𝑉ˆ𝑛+1 =

(5.3.3)


 𝑉𝜆 × 𝑅 , Δ𝑡 ≥ 𝑓
, Δ𝑡 > 𝑑

0


where
Δ𝑡 = 𝑡ˆ𝑛 − 𝑡 (5.3.4)
and we update the reference time after the two previous compu-
tations such that:

,𝑡 =0



 𝑡


𝑡ˆ𝑛+1 = 𝑡ˆ𝑛 , Δ𝑡 < 𝑓 (5.3.5)

, Δ𝑡 ≥ 𝑓

𝑡


The quoter then provides a quotation price based on the constant-
product formula and adds a dynamic fee charged on the output:

𝑉2 ×𝜙
Δ𝑂𝑢𝑡 × 𝜆 (5.3.6)
100
Where Δ𝑂𝑢𝑡 represents the output amount and 𝜙 is a fee control
parameter used for scaling.

6 SUMMARY
Steamm is an advanced Automated Market Maker that maximizes
liquidity efficiency, through its native money market integration,
and adaptability through its modular quotation design. By enabling
various swap quotation models, including constant-product, stable,
and dynamic-fee AMMs, Steamm supports diverse trading needs,
offering robust flexibility and enhanced liquidity management.
A key innovation is Steamm’s liquidity re-utilization model.
Unlike traditional AMMs where liquidity often sits idle, Steamm
channels unused liquidity into lending markets via an abstraction
called Bank, generating additional yield for liquidity providers.
Through the use of bTokens, earned yield flows back into liquidity
4