STEAMM Integration

The STEAMM SDK can be found here: https://www.npmjs.com/package/@suilend/steamm-sdk.

Click here to access the STEAMM Github repo. Any other questions? Head to the STEAMM channel on the Suilend Discord.

If you wish to play around with STEAMM on testnet we provide a fully integrated set of shell scripts to deploy the entire STEAMM suite with it's Suilend dependencies here : https://github.com/userdarius/steamm-testnet

STEAMM Developer Integration Guide

Table of Contents

  1. Overview

  2. Architecture

  3. Quick Start

  4. Pool Types

  5. Creating Pools

  6. Liquidity Operations

  7. Swapping

  8. Suilend Integration

  9. Advanced Usage

  10. Error Handling

  11. Practical Integration

  12. Code Examples

  13. Reference

Overview

STEAMM is a next-generation Automated Market Maker (AMM) protocol on Sui that maximizes capital efficiency through:

  • Modular Quoter System: Support for multiple AMM types (Constant Product, Oracle-based, Stable)

  • Liquidity Reutilization: Optional integration with Suilend lending markets for yield generation

  • Shared Liquidity Model: Banks aggregate liquidity across pools for improved efficiency

  • Yield-bearing LP Tokens: LPs earn both trading fees and lending yields

Key Benefits for Developers

  1. Flexible Integration: All pools use banks for liquidity management, with optional yield farming via Suilend

  2. Capital Efficiency: Up to 80% of idle liquidity can earn lending yields (when enabled)

  3. Multiple AMM Types: Constant product, oracle-based, and stable coin AMMs

  4. Composable Design: Easy integration with existing DeFi protocols

Architecture

Core Components

  • Registry: Global tracker of all pools and banks

  • Pool: Core AMM logic with modular quoter system

  • Bank: Manages liquidity and optional Suilend integration

  • Quoter: Pluggable AMM algorithms (CPMM, Oracle, Stable)

Token Flow

Quick Start

Dependencies

Add to your Move.toml:

Basic Pool Creation

Important: All pools require banks and use bToken types. Banks must be created first.

Basic Liquidity Operations

Note: Use pool_script_v2 functions for all pools as they handle the required bank operations:

Pool Types

STEAMM supports three main quoter types:

1. Constant Product AMM (CPMM)

Best for: General trading pairs, volatile assets

Requirements: Banks and bTokens are required for all tokens. You only need to create banks for tokens that don't already have them.

Features:

  • Classic x*y=k formula with optional offset

  • Suitable for most token pairs

  • Predictable slippage curves

  • Requires banks for liquidity management

2. Oracle AMM (OMM)

Features:

  • Uses external price feeds

  • Requires Suilend integration (bTokens only)

3. Stable AMM (Oracle Quoter V2 with High Amplifier)

Current Implementation: Oracle Quoter V2 with amplifier A = 1000

Features:

  • Uses Curve StableSwap invariant with oracle prices

  • High amplifier (A = 1000) provides minimal slippage for stable pairs

  • Combines oracle price feeds with stable swap mathematics

  • Dynamic amplifier adjustment based on pool balance ratios

  • Requires Suilend integration (bTokens only)

Creating Pools

Bank Creation Methods

Before creating pools, you need to create banks for any tokens that don't already have them. STEAMM provides two methods for bank creation:

Method 1: Simple Bank Creation (Recommended for most cases)

Method 2: Bank Builder Pattern (For advanced setup)

The create_bank() function is package-only, so external protocols must use the builder pattern:

When to use each method:

  • Use create_bank_and_share() for standard bank creation

  • Use the builder pattern only when you need to configure the bank before it becomes shared (advanced use cases)

Fee Tiers

STEAMM supports multiple fee tiers to accommodate different asset pairs and trading scenarios. All fees are specified in basis points (bps), where 100 bps = 1%.

Available Fee Tiers:

Fee (bps)
Fee (%)
Recommended Use Case

1

0.01%

Ultra-stable pairs (e.g., USDC/USDT)

5

0.05%

Stable pairs with high correlation

10

0.10%

Correlated assets

20

0.20%

Standard stable pairs

25

0.25%

Slightly volatile pairs

30

0.30%

Standard trading pairs (most common)

50

0.50%

Volatile asset pairs

100

1.00%

High volatility pairs

200

2.00%

Very volatile or exotic pairs

1000

10.00%

Extremely high risk pairs

5000

50.00%

Experimental or very high risk

Fee Selection Guidelines:

  • Stable pairs (USDC/USDT): Use 1-10 bps for minimal slippage

  • Standard pairs (ETH/USDC): Use 30 bps (0.3%) as the default

  • Volatile pairs: Use 50-100 bps to compensate for higher risk

  • Exotic pairs: Use higher fees (200+ bps) for increased LP protection

Pool Creation with Existing Banks

When creating pools for tokens that already have banks (like SUI):

Advanced Pool with Suilend Integration

For yield-bearing pools that earn lending yields:

Liquidity Operations

Adding Liquidity

All pools require banks and should use the script functions:

Removing Liquidity

All pools require banks and should use the script functions:

Swapping

Understanding STEAMM's Swap Model

STEAMM uses a direct swap model where swaps are executed immediately:

  1. Quote: Get a quote for the intended swap amount

  2. Provision: Banks automatically provision necessary liquidity from Suilend (for yield pools)

  3. Swap: Perform the swap in a single transaction

  4. Rebalance: Banks automatically rebalance utilization as needed

Pool Swaps

Always use pool_script_v2 for all pools - it handles the required bank operations and bToken conversions:

Oracle Pool Swaps

Getting Quotes

Always get quotes before executing swaps: Important: Quote functions return amounts in bToken values, not underlying token values. For pools without lending, bTokens have a 1:1 ratio with underlying tokens. For yield pools with active lending, the bToken:underlying ratio may differ due to accrued lending returns.

Script Versions: When to Use Which

The choice between script versions depends on gas costs and lending market access requirements:

  • pool_script_v2: RECOMMENDED - Uses immutable &LendingMarket

    • Lower gas costs due to immutable reference

    • Suitable for most swap operations

    • Cannot perform preemptive rebalancing

  • pool_script: Uses mutable &mut LendingMarket

    • Higher gas costs due to mutable reference

    • Required when large withdrawals need preemptive rebalancing

    • Allows modification of lending market state

    • Use only when pool_script_v2 fails due to rebalancing needs

  • Direct pool calls: Not recommended - use script functions instead

When to use pool_script:

  • Large withdrawal operations that trigger rebalancing requirements

  • When you encounter errors related to insufficient liquidity that require preemptive rebalancing

  • As a fallback when pool_script_v2 operations fail

Default recommendation: Always try pool_script_v2 first for better gas efficiency, fallback to pool_script only when necessary.

Suilend Integration

Understanding Banks

Banks are the key component that enables Suilend integration:

  • Purpose: Aggregate liquidity from multiple pools

  • Yield Generation: Deploy idle liquidity to Suilend for lending yields

  • bTokens: Yield-bearing representations of underlying tokens (note: singular "btoken")

  • Utilization Management: Maintain liquidity buffers for instant swaps

Bank Lifecycle

  1. Creation: bank::create_bank_and_share() or builder pattern - Creates bank for a token type

  2. Lending Setup: bank.init_lending() - Enables Suilend integration (admin-gated, only Suilend can toggle)

  3. Operation: Automatic yield generation and liquidity management

  4. Rebalancing: Periodic adjustment of Suilend exposure

Working with bTokens

Utilization Parameters

Admin Access Required: init_lending is admin-gated and can only be called by Suilend administrators.

Target Utilization: Percentage of bank funds deployed to Suilend Buffer: Allowed deviation before rebalancing occurs

Benefits of Suilend Integration

  1. Additional Yield: LPs earn trading fees + lending yields

  2. Capital Efficiency: Up to 80% of idle liquidity generates yield

  3. Shared Liquidity: Multiple pools share deeper liquidity

  4. Automatic Management: Protocol handles Suilend interactions

When to Enable Suilend Lending

All pools use banks, but lending integration is optional and requires admin permission:

Enable Lending Integration When:

  • You want maximum yield for LPs

  • Pool expects significant idle periods

  • Working with established tokens (USDC, SUI, etc.)

  • Token has an active Suilend market

Keep Lending Disabled When:

  • Working with new/experimental tokens

  • Token doesn't have a Suilend market

  • Minimizing yield complexity

  • Rapid prototyping phases

Error Handling

Common Error Codes

Error
Code
Description
Solution

ESlippageExceeded

0

Output below minimum

Increase slippage tolerance

EInsufficientBankFunds

9

Bank liquidity too low

Wait for rebalancing or provide liquidity

ELendingAlreadyActive

5

Bank already has lending initialized

Check bank state before init

EInvalidBTokenDecimals

1

bToken must have 9 decimals

Fix token metadata

EInvalidLpDecimals

0

LP token must have 9 decimals

Fix LP token metadata

EEmptyBank

1

Bank has no funds

Add liquidity first

EInvariantViolation

0

CPMM invariant broken

Check swap parameters

Error Handling Patterns

Practical Integration

Integrating STEAMM into Your DeFi Protocol

1. Simple Swap Integration

2. Yield Farming Integration

3. Arbitrage Bot Integration

Advanced Usage

Multi-Pool Routing

Fee Management and Revenue

Monitoring Pool Health

Code Examples

Complete Pool Setup

Trading Interface

Reference

Key Functions by Component

Registry

  • registry::init_for_testing() - Create registry for testing

  • Auto-registration happens when creating pools/banks

Bank

  • bank::create_bank_and_share() - Create and share new bank (simple method)

  • bank::new() / builder.build() - Create bank via builder pattern (advanced method)

  • bank.init_lending() - Enable Suilend integration (admin-gated)

  • bank.mint_btoken() - Convert tokens to bTokens (singular!)

  • bank.burn_btoken() - Convert bTokens back to tokens (singular!)

  • bank.rebalance() - Manual rebalancing trigger

Pool

  • pool.deposit_liquidity() - Add liquidity

  • pool.redeem_liquidity() - Remove liquidity

  • pool.cpmm_swap() - Execute CPMM swap

  • pool.cpmm_quote_swap() - Get CPMM quote

Quoters

  • cpmm::new() - Create constant product pool

  • omm_v2::new() - Create oracle AMM pool (requires full parameters)

  • Various swap() and quote_swap() functions

Scripts (Recommended)

  • pool_script_v2::deposit_liquidity() - PREFERRED - Add liquidity with banks

  • pool_script_v2::redeem_liquidity() - PREFERRED - Remove liquidity with banks

  • pool_script_v2::cpmm_swap() - PREFERRED - Swap with banks

  • pool_script_v2::quote_cpmm_swap() - PREFERRED - Quote with banks

Gas Optimization Tips

  1. Use Scripts: Always use pool_script_v2 functions for yield pools

  2. Batch Operations: Combine multiple operations when possible

  3. Pre-calculate: Get quotes off-chain when possible

  4. Rebalance Timing: Banks auto-rebalance, but manual triggers available

  5. Avoid Micro-transactions: Respect minimum token block sizes

Testing

Migration and Versioning

STEAMM uses versioned contracts. When integrating:

  1. Always check current versions in Move.toml files

  2. Use the latest published package addresses

  3. Handle version upgrades gracefully

  4. Test with the exact versions you'll use in production

Best Practices

  1. Start Simple: Begin with basic CPMM pools, add yield later

  2. Use Scripts: Always prefer pool_script_v2 for yield pools

  3. Monitor Health: Regularly check bank utilization and rebalancing needs

  4. Handle Errors: Implement proper error handling for common failure modes

  5. Test Thoroughly: Use the provided test utilities extensively

  6. Gas Awareness: Be mindful of gas costs, especially for bank operations

Last updated