# Aerodrome Ignition
Source: https://docs.arrakis.finance/aerodrome-ignition



[Aerodrome Ignition](https://aerodrome.finance/) is the leading token launch mechanism on Base, combining transparent price discovery, broad distribution, and onchain liquidity bootstrapping into a single onchain framework. Ignition gets teams to day-one liquidity through veAERO emissions, but the harder problem comes after. By Epoch 2, mercenary LPs are rotating capital in to farm AERO emissions and out the moment rewards are claimed, leaving thin liquidity behind to absorb sell pressure.

Projects that enter that phase with thin quote-side reserves and passive liquidity see slippage spike and become dependent on emissions-driven LP capital that is structurally unreliable during sell-offs.

Arrakis Pro deploys a managed vault on Aerodrome that runs the [**Bootstrap Strategy**](/bootstrap) through Epoch 1 to accumulate ETH or USDC reserves as buyers enter the pool, then auto-transitions to the [**Flagship Strategy**](/flagship) in Epoch 2 to maintain concentrated depth through the mercenary LP rotation cycle.

Concentrated active management has historically delivered approximately 4x greater depth per dollar deployed than full-range protocol-owned liquidity, accelerating the pool's transition from emissions-dependent to fee-sustainable. The team keeps self-custody through the vault NFT throughout.

## What Ignition delivers

Ignition uses Aerodrome's ve(3,3) emissions flywheel as the launch mechanism. The project deposits a portion of its token supply as voting incentives for an Aerodrome pool. veAERO holders vote for that pool to capture the incentives, directing AERO emissions to it. AERO emissions stream as liquidity rewards the following week, attracting LPs who deposit capital and deepen the market. Deeper liquidity reduces slippage and improves execution, attracting more onchain volume, which generates fee revenue that attracts additional veAERO votes in subsequent epochs.

For the full Ignition mechanism, see [**Aerodrome's documentation**](https://aerodrome.finance/docs).

Ignition runs on Aerodrome's epoch cycle. Epochs run Wednesday to Wednesday and define the two key phases of a launch:

| Phase                  | What happens                                                                     | What matters for liquidity                                            |
| ---------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| Epoch 1 (Bootstrap)    | Project deposits POL; LPs farm initial AERO emissions; price discovery plays out | Build quote-side reserves before bribe-driven competition intensifies |
| Epoch 2 (Distribution) | veAERO voters claim bribes; mercenary LPs farm and rotate out                    | Maintain depth and absorb sell pressure through the rotation cycle    |

## Why Week 2 determines launch outcomes

Three dynamics emerge as Ignition's launch sequence plays out. Each is fixed by deploying the position through Arrakis active management.

<Columns>
  <Card title="Most teams enter TGE without enough quote-side reserves.">
    Building real depth on a DEX requires ETH or USDC, and most projects come to TGE with a surplus of their own token but limited quote-side capital. The realistic alternatives are to drain treasury, OTC the gap, or accept thin liquidity. With Arrakis, the Bootstrap Strategy deploys liquidity in asymmetric ranges weighted toward the project token and accumulates ETH or USDC as buyers enter the pool through Epoch 1. By the time Epoch 2 starts, inventory has progressively rebalanced toward a healthier quote-side ratio without treasury deployment.
  </Card>

  <Card title="Mercenary LPs exit at epoch close, draining depth.">
    Incentive-driven LPs deposit capital to farm AERO emissions and rotate out the moment rewards are claimed. The buy-LP-farm-sell cycle repeats every epoch and is structurally unreliable during sell-offs. Projects entering Epoch 2 with thin reserves watch slippage spike as those LPs exit. With Arrakis, the Flagship Strategy keeps concentrated depth at the trading price through the mercenary rotation cycle and absorbs the sell pressure that thin liquidity amplifies.
  </Card>

  <Card title="Static POL underperforms by 4x.">
    Most projects historically deployed protocol-owned liquidity as full-range positions: the simplest setup, but capital-inefficient. The majority of the capital sits far from the trading price where it produces no fees and no depth. With Arrakis, concentrated active management has historically delivered approximately 4x greater depth per dollar deployed than full-range positions while generating more fees per dollar, accelerating the pool's transition from emissions-dependent to fee-sustainable.
  </Card>
</Columns>

## Launch flow with Arrakis

The Arrakis flow for an Ignition launch is pre-launch configuration, followed by an automatic two-strategy handoff once trading begins.

```mermaid theme={null}
flowchart LR
    Start([Pre-launch:<br/>Vault configured<br/>before TGE])
    --> E1[Epoch 1<br/>Bootstrap Strategy<br/>Accumulate quote assets<br/>via asymmetric ranges]
    E1 -- "Target inventory<br/>ratio reached" --> E2[Epoch 2<br/>Flagship Strategy<br/>Volatility-adaptive<br/>concentration at spot]
    E2 --> Steady([Steady state:<br/>Active management<br/>through ongoing epochs])
```

<Steps>
  <Step title="Pre-launch configuration">
    The team and Arrakis confirm vault parameters: pool type (typically CL100 for volatile pairs), tick spacing, Bootstrap Strategy schedule (target inventory ratio, range distribution, conversion timeline), and oracle source (Chainlink, Redstone, or fallback TWAP). The Aerodrome pool is created or confirmed, the token is whitelisted in the Aerodrome Voter contract, and the pool Gauge is created so the pool receives AERO emissions.
  </Step>

  <Step title="Vault deployment">
    The Arrakis Aerodrome vault is deployed on Base. The team's POL is deposited into the vault, which deploys the configured Bootstrap position into the Aerodrome pool. LP positions auto-stake to receive AERO emissions. Vault ownership transfers to the team's multisig.
  </Step>

  <Step title="Epoch 1 (Bootstrap)">
    Trading goes live. The Bootstrap Strategy holds liquidity in asymmetric ranges weighted toward the project token. As buyers enter the pool, the position captures quote assets and rebalances around the new spot. AERO emissions accrue continuously.
  </Step>

  <Step title="Auto-transition">
    Once inventory reaches the configured target ratio (typically 50/50), the vault auto-transitions to the Flagship Strategy. No manual handoff is required.
  </Step>

  <Step title="Epoch 2 (Flagship) and beyond">
    The Flagship Strategy concentrates around the trading price in calm markets and widens during sell-offs. The position maintains depth through the mercenary LP rotation cycle and continues to capture fees as the pool transitions from emissions-driven to fee-driven sustainability.
  </Step>
</Steps>

## Arrakis benefits

After deployment, the vault is actively managed by Arrakis Pro's strategy infrastructure. Liquidity stays on Aerodrome throughout. The team keeps self-custody through the vault NFT.

|                                    | Static POL (full-range)      | Arrakis-managed POL                   |
| ---------------------------------- | ---------------------------- | ------------------------------------- |
| **Capital at trading price**       | Small fraction               | Majority                              |
| **Quote-side inventory at launch** | Depends on market buying     | Accumulates organically via Bootstrap |
| **Epoch 2 depth**                  | Drains as mercenary LPs exit | Maintained by Flagship                |
| **AERO emissions**                 | Manual stake                 | Auto-staked to gauge                  |
| **Rebalancing**                    | None                         | Continuous, automated                 |
| **Operations**                     | Self-managed                 | Managed by Arrakis                    |
| **Custody**                        | Self-custodial (LP NFT)      | Self-custodial (Arrakis vault NFT)    |

## Engaging before launch

Bootstrap accumulates quote assets from the first trade onward. That only works if the vault is deployed and configured before the pool goes live. Aerodrome's epoch cycle runs Wednesday to Wednesday on a fixed schedule. Teams that enter Epoch 2 with thin reserves do not get a second attempt at Epoch 1.

Pre-launch coordination covers:

* Pool selection (typically CL100 for volatile launches, with tick spacing matched to expected volatility)
* Bootstrap Strategy parameters: target inventory ratio, range distribution, conversion schedule
* Oracle setup: Chainlink, Redstone, or fallback TWAP
* Token whitelisting in the Aerodrome Voter contract
* Pool Gauge creation so the pool is eligible for AERO emissions
* Vault ownership transfer to the team's multisig

The full pre-deployment checklist runs ahead of the TGE date so the vault is live and ready when trading opens.

## Supported deployments

The Arrakis Aerodrome module is deployed on Base, where Aerodrome operates.

<Card title="Integrate Arrakis" icon="laptop" href="https://qxqhpatmzz7.typeform.com/to/IZdNgmmM?typeform-source=docs.arrakis.finance">
  Talk to Arrakis  before your Ignition launch.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="How does the Bootstrap → Flagship handoff work?">
    The Bootstrap Strategy tracks the vault's inventory ratio against the configured target. When the ratio reaches the target (typically 50/50), the vault auto-transitions to the Flagship Strategy. No manual handoff is required and there is no withdrawal step. Flagship takes over ongoing management with volatility-adaptive concentration around spot.
  </Accordion>

  <Accordion title="What if our pool does not see enough buy pressure during Epoch 1 to accumulate quote reserves?">
    The Bootstrap Strategy is bounded by organic trading volume. In a low-volume Epoch 1, conversion runs slower and inventory may still be skewed entering Epoch 2. Aggressive Bootstrap configurations convert faster at progressively higher prices as the position is consumed. Teams that expect thin buy pressure can also seed additional quote-side capital into the vault to shorten the bootstrap window. The strategy is configurable per launch profile.
  </Accordion>

  <Accordion title="Can we change strategy parameters after launch?">
    Yes. Tick range, fee tier, Bootstrap target ratio, schedule, and the active strategy are all reconfigurable. Reconfiguration runs as an authenticated call from the vault NFT holder.
  </Accordion>

  <Accordion title="What pool type should we use for an Ignition launch?">
    CL100 (1% tick spacing) is the typical default for volatile Ignition launches. Tighter tick spacing (CL50 or CL10) suits less volatile pairs; wider tick spacing (CL200, CL2000) suits highly volatile or emerging assets. Pool selection is part of pre-launch configuration and is coordinated with Arrakis based on expected volatility and the asset class.
  </Accordion>
</AccordionGroup>


# Arrakis Pro
Source: https://docs.arrakis.finance/arrakis-pro



Arrakis Pro is a non-custodial onchain market maker for token issuers. It manages concentrated liquidity on DEXs through self-custodial vaults: the issuer owns the vault and the assets in it, and Arrakis runs the market-making strategy within the parameters the issuer sets. The result is treasury-owned liquidity that is actively managed without the issuer operating it.

Across live deployments, Arrakis Pro manages liquidity for over 100 token issuers and has facilitated more than \$5B in onchain volume.

## The problem

Concentrated liquidity, introduced by Uniswap v3, allows LPs to provide deeper markets per dollar than standard full-range positions by concentrating capital around the trading price. That capital efficiency comes at an operational cost: as the price moves the position must be continuously rebalanced, fees must be tuned to volatility, and inventory must be actively managed to stay in range. For teams managing this in house, it generally requires a full-time quant function. Without active management, concentrated positions quickly fall out of range, stop earning fees, and leak value to arbitrageurs and active LPs.

Arrakis Pro manages this automatically. Teams deposit into a vault, select their strategy, and Arrakis manages the position continuously: rebalancing as the price moves, adjusting fees to market conditions, and keeping liquidity concentrated where trading happens.

## How Arrakis Pro works

Arrakis Pro is built from two components: an onchain smart-contract framework and an offchain market-making system.

```mermaid theme={null}
flowchart TB
    Issuer([Token issuer owns the vault NFT, self-custodial])
    Issuer --> Vault
    subgraph On[Onchain: Arrakis Modular]
      Vault[Arrakis Pro vault, DEX module, optional v4 hook]
    end
    subgraph Off[Offchain: Arrakis market-making infrastructure]
      Strat[Strategy execution: rebalancing, dynamic fees, monitoring]
    end
    Strat -- "rebalance and fee instructions" --> Vault
    Vault -- "deploys concentrated liquidity" --> Pool([DEX pool])
```

**The vault is self-custodial.** Each Arrakis Pro vault is owned by the team and represented by an NFT, the way a Uniswap v3 position is. Whoever holds the vault NFT controls the assets and can pause, reconfigure, or withdraw at any time. Arrakis adjusts the strategy as part of active management, while changes to the vault's core parameters are subject to a two-day timelock, giving the owner time to review or exit. Because the NFT carries withdrawal rights, transferring it transfers control of the underlying funds.

**Arrakis Modular is the onchain framework.** The vault is a modular smart contract: a core vault, a per-DEX module that holds the liquidity, and an optional Uniswap v4 hook for features like dynamic fees. Arrakis's modular design allows it to run on any concentrated-liquidity DEX rather than a single venue, and a vault to move between DEXs or add capabilities without redeploying.

**The offchain infrastructure runs the strategy.** Arrakis's market-making system monitors price, volatility, and inventory, computes when and how to rebalance, sets dynamic fees, and submits those instructions to the vault. It operates continuously, with no gas cost or manual action required from the team.

## Strategies

Each vault runs a strategy chosen by the team:

<Columns>
  <Card title="Bootstrap" icon="rocket" href="/bootstrap">
    Accumulates quote-side assets (ETH or stablecoins) at launch when inventory is skewed toward the project token, then auto-transitions to Flagship.
  </Card>

  <Card title="Flagship" icon="anchor" href="/flagship">
    The ongoing strategy for mature markets, concentrating around spot and adapting to volatility.
  </Card>

  <Card title="Yield-Bearing Asset" icon="percent" href="/yield-bearing-asset">
    Holds sell-side depth in range for tokens that accrue value through yield.
  </Card>

  <Card title="Treasury Diversification" icon="coins" href="/treasury-diversification">
    Converts project tokens into quote assets over time through organic trading.
  </Card>
</Columns>

Arrakis also builds customized strategies for pairs with specific requirements.

## Features

Uniswap v4 hooks add capability on top of a strategy, configured at deployment:

<Columns>
  <Card title="Price Convergence" icon="crosshairs" href="/price-convergence">
    Aligns the pool price with an external reference, for RWAs that track an off-chain value and for matching a CEX listing price at launch.
  </Card>

  <Card title="Dynamic Fees" icon="gauge" href="/dynamic-fees">
    Adjusts the fee tier to volatility and trading momentum, capturing more on volatile flow and less on quiet flow.
  </Card>
</Columns>

## Getting started

<Steps>
  <Step title="Deploy and configure">
    Arrakis deploys and configures the vault on the team's behalf.
  </Step>

  <Step title="Transfer the vault NFT">
    Arrakis transfers the vault NFT to the team's multisig. The team keeps custody throughout.
  </Step>
</Steps>

To get started, [contact us](https://qxqhpatmzz7.typeform.com/to/IZdNgmmM?typeform-source=docs.arrakis.finance).


# Audits
Source: https://docs.arrakis.finance/audits



Arrakis smart contracts have been audited by world class security firms.

## ChainSecurity

* Aerodrome Module Audit Report (Jan 2025)
* Uniswap V4 Private and Public Modules Audit Report (Dec 2024)
* Arrakis Modular (Core) Audit Report (Jul 2024)

## Sherlock

* Uniswap V4 PrivateHook & Price Convergence Audit Report (Jan 2026)
* Uniswap V3 Module & Pauser Audit Report (Jan 2026)
* Uniswap V4 Public Module Audit Report (Jul 2025)
* Migration and Withdraw Helper Audit Report (Mar 2025)
* Valantis SOT Module Audit Report (Jun 2024)

## Watchpug

* Uniswap V3 Module & Pauser Audit Report (Dec 2025)
* Arrakis Modular (Core) Audit Report (Mar 2023)

## Enigma Dark

* Uniswap V4 Private Hook & Price Convergence Audit Report (Nov 2025)
* PancakeSwap V3 Module Audit Report (Sep 2025)
* Uniswap V4 Public Module Audit Report (Jul 2025)
* PancakeSwap V4 & Uniswap V4 Modules Audit Report (Apr 2025)

## Cantina

* Uniswap V3 Module & Pauser Audit Report (Jan 2026)
* PancakeSwap V3 Module Audit Report (Sep 2025)

## Pashov Audit Group

* Uniswap V4 V2 & PancakeSwap V4 V2 Modules & Standard Manager Audit Report (Mar 2026)

## Reporting a vulnerability

To report a security vulnerability, email [security@arrakis.finance](mailto:security@arrakis.finance).

## Requesting reports

Audit reports are available on request. [Request access](https://form.typeform.com/to/brsaXsRD).


# Binance Alpha
Source: https://docs.arrakis.finance/binance-alpha



Binance Alpha is an exchange-affiliated distribution program. Projects launching on Binance Alpha gain exposure to Binance's user base, and the program requires the project to seed and maintain a qualifying onchain liquidity pool. The program specifies the setup: a single official pool on a venue Binance designates, on a low fee tier, with hooks not permitted in that pool.

That required position is capital-intensive and has to survive a volatile launch window. Sniping at open and airdrop recipients selling once rewards unlock drive intense one-directional flow that skews a static position and widens price impact. Arrakis Pro deploys and actively manages the required position so the same capital holds depth at the trading price and absorbs the sell pressure, rather than sitting full-range while that flow extracts value from it. The team keeps self-custody through the vault NFT.

## What Binance Alpha requires

Binance Alpha handles distribution: frontend exposure, access to Binance's user base, and for some projects a path toward spot listing. The liquidity requirement is the part Arrakis operates against.

| Program sets | Detail                                                       |
| ------------ | ------------------------------------------------------------ |
| Pool         | A single official pool the project seeds and maintains       |
| Venue        | A DEX and chain Binance designates, generally not negotiable |
| Fee tier     | A low fee tier set by the program                            |
| Hooks        | Not permitted in the official pool                           |

These are program mechanics, not Arrakis constraints. They shape what Arrakis can and cannot do inside the Alpha pool. For the program's full terms, speak with the Binance team.

## Why liquidity management matters here

The launch window is the hard part. Three dynamics shape whether the required position survives it, and active management addresses each.

<Columns>
  <Card title="A static position spreads the required capital where trades do not happen.">
    Posting the required capital as a full-range position is the simplest way to meet the requirement, but the majority of it sits far from the trading price and contributes nothing to depth during the window that matters most. With Arrakis, the same capital is deployed as an actively managed concentrated position. Concentrated management has historically delivered approximately 4x greater depth per dollar than a full-range position, so the required capital does more work precisely when sniping and airdrop flow hit hardest.
  </Card>

  <Card title="The launch window drives one-directional flow that skews a passive position.">
    Snipers buy aggressively at open, and airdrop recipients sell into the pool once rewards unlock. A static position absorbs that flow blindly: inventory skews hard toward the token as recipients dump, price impact widens, and teams without active management end up making manual adjustments by hand in the first minutes of trading. With Arrakis, the [**Flagship Strategy**](/flagship) rebalances continuously, keeps liquidity concentrated around the moving trading price, and manages the inventory skew as sell pressure arrives, with no manual intervention from the team.
  </Card>

  <Card title="The low fee tier earns almost nothing back.">
    At the low fee tier the program sets, the Alpha pool generates little fee income to offset the impermanent loss the volatile flow produces. Fee income is not where this pool earns its keep, so capital efficiency and inventory management are the levers that matter.
  </Card>
</Columns>

## Launch flow with Arrakis

```mermaid theme={null}
flowchart LR
    Pre([Pre-launch:<br/>Vault configured to meet<br/>Binance requirements])
    --> Open[Launch window<br/>Flagship defends depth<br/>through sniping]
    Open --> Air[Airdrop unlock<br/>Manage inventory skew<br/>as recipients sell]
    Air --> Steady([Steady state:<br/>Ongoing active management])
```

<Steps>
  <Step title="Pre-launch configuration">
    The team and Arrakis confirm the vault meets Binance's requirements: the required position, the specified fee tier, the designated DEX and chain, and a Flagship Strategy configuration tuned for the launch window. Because Binance reviews the setup, parameters are confirmed against the program's requirements ahead of the TGE date.
  </Step>

  <Step title="Vault deployment">
    The vault is deployed on the specified venue and seeds the required position.
  </Step>

  <Step title="Launch window">
    Trading opens. Flagship keeps liquidity concentrated around the trading price and rebalances continuously as snipers buy in, holding depth where execution happens rather than spreading it thin.
  </Step>

  <Step title="Airdrop unlock">
    As airdrop recipients sell into the pool, the strategy manages the resulting inventory skew and widens or repositions as conditions warrant, absorbing sell pressure instead of amplifying it.
  </Step>

  <Step title="Steady state">
    Active management continues. The team can pause, reconfigure, or withdraw at any time.
  </Step>
</Steps>

## Arrakis benefits

Within Binance's requirements, the choice is between posting a static position and actively managing it. The required capital is the same either way.

|                              | Static full-range position                | Arrakis-managed position              |
| ---------------------------- | ----------------------------------------- | ------------------------------------- |
| **Capital at trading price** | Small fraction                            | Majority, concentrated around spot    |
| **Sniping window**           | Absorbs flow blindly, price impact widens | Rebalances continuously to hold depth |
| **Airdrop sell pressure**    | Inventory skews into the token unmanaged  | Inventory skew actively managed       |
| **First minutes of trading** | Manual adjustments by the team            | Automated, no team intervention       |
| **Operations**               | Self-managed                              | Managed by Arrakis                    |
| **Custody**                  | Self-custodial (LP NFT)                   | Self-custodial (Arrakis vault NFT)    |

## Supported deployments

Arrakis operates the Binance Alpha pool on the venue and chain Binance sets for the launch. Arrakis Pro supports the major DEXs chosen as the liquidity venue. The venue and chain are part of the program terms and generally not negotiable, so the Arrakis setup is built to fit them.

<Card title="Integrate Arrakis" icon="laptop" href="https://qxqhpatmzz7.typeform.com/to/IZdNgmmM?typeform-source=docs.arrakis.finance">
  Talk to the Arrakis team about your Binance Alpha launch.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="What happens to the position when airdrop recipients sell?">
    Airdrop unlocks drive sell pressure into the pool, which skews inventory toward the project token. The Flagship Strategy manages that skew, rebalancing and repositioning as the flow arrives rather than letting the position absorb it passively. The position cannot eliminate sell pressure, but active management limits the price impact and inventory damage relative to a static position.
  </Accordion>

  <Accordion title="After the Binance Alpha commitment period, can we move to a standard Arrakis setup?">
    Yes. Once the program's liquidity commitment period ends, the position can be reconfigured or migrated to a standard Arrakis vault on Uniswap v4 or another venue with a higher fee tier, where the full strategy and hook set applies (dynamic fees, [**Price Convergence**](/price-convergence), [**Treasury Diversification**](/treasury-diversification)). Reconfiguration runs as an authenticated call from the vault NFT holder.
  </Accordion>
</AccordionGroup>


# Bootstrap
Source: https://docs.arrakis.finance/bootstrap

Build quote-side reserves at launch from a token-heavy start, using organic trading instead of OTC deals or loans, then auto-transition to Flagship.

Arrakis Pro's Bootstrap strategy lets token issuers build quote-side reserves (ETH or stablecoins) when their inventory is heavily skewed toward the project token, while keeping deep onchain liquidity for trading. It builds the quote side from organic trading demand instead of OTC deals or loans. It fits projects launching a new pool, for example at a Token Generation Event, that hold mostly their own token and not enough ETH or stablecoins to seed a balanced market.

Bootstrap differs from [Treasury Diversification](/treasury-diversification) in goal and timing. Bootstrap runs at launch to stand up a balanced, deep liquidity position from a token-heavy start. Treasury Diversification runs later, converting a project's token holdings into a quote asset over time for treasury management.

The team can deposit up to 100% project token. As the market trades through the strategy's positions, the inventory converges toward a balanced ratio (typically 50/50) while the pool keeps depth for trading.

## How it works

With Arrakis, the team sets:

* The starting inventory (for example 90–100% project token).
* The target inventory ratio for the transition out of Bootstrap (typically 50/50) into the Flagship Strategy.

The strategy deploys the inventory across three position types around the spot price:

<Columns>
  <Card title="Full Range" icon="arrows-left-right">
    A wide position that acts as the main stabilizer. It absorbs the quote captured as the Bootstrapping Ranges convert through trading.
  </Card>

  <Card title="Bootstrapping Ranges" icon="layer-group">
    Short, sequential ranges of increasing size, each holding only the project token at first. Near-spot ranges convert gradually with minimal  impact. Further-out ranges capture upside if the price moves sharply. Together they produce near-symmetric price impact, so buys and sells see comparable slippage even when the  inventory is  skewed.
  </Card>

  <Card title="Price Discovery Range" icon="arrow-trend-up">
    A long-range position that captures additional upside if the price rises sharply.
  </Card>
</Columns>

As the market trades through a Bootstrapping Range, the project token in that range converts into quote, which is absorbed into the Full Range stabilizer. The vault repositions automatically as spot moves, rebuilding the Bootstrapping Ranges around the new price and holding the configured distribution. The inventory converges toward the target ratio. Conversions are filled entirely by counterparties trading on the DEX.

<Note>
  **TWAP protection.** Every rebalance is checked against a TWAP (time-weighted average price) that blocks responses to short-lived price spikes, guarding the vault against price manipulation and keeping the strategy from reacting to noise.
</Note>

When the inventory reaches the target ratio, the vault auto-transitions to the [Flagship Strategy](/flagship), which takes over ongoing management with volatility-adaptive width and tighter management around spot. No manual handoff is required. The team can pause, reconfigure, or withdraw at any time.

## Considerations

<Card title="Pace is bounded by market activity.">
  Bootstrap converts the project token as the market trades through the strategy's positions. In a low-volume market, conversion takes longer. Configuring positions more aggressively converts faster, but at progressively higher prices on the way up.
</Card>

<Card title="Asymmetric exposure during conversion.">
  Bootstrap is path-dependent. If the price rises sharply, the strategy converts at progressively higher prices but ends with less project token. If the price falls before much has converted, the team holds more project token at lower prices. The strategy mitigates exposure to either path but does not remove it.
</Card>

<Card title="The strategy reduces but does not eliminate impermanent loss.">
  Bootstrap is an LP strategy that starts with the project token as the bulk of the inventory. LP positions still produce impermanent loss through large directional moves relative to holding the tokens directly. The strategy mitigates the magnitude, not the risk.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="What inventory do we need to bootstrap?">
    Bootstrap accepts up to 100% project token. The quote side is built through trading, so the team does not need to source ETH or stablecoins up front through OTC deals or loans.
  </Accordion>

  <Accordion title="How long does Bootstrap take to complete?">
    Conversion time depends on the inventory skew, the target ratio, and organic trading volume. In a moderately active market, conversion plays out over weeks to a month. Low-volume markets take longer. The target ratio is reached when the market has organically converted enough of the project token. The strategy does not force conversion by market-selling.
  </Accordion>

  <Accordion title="What happens if the price drops before Bootstrap completes?">
    The strategy widens positions and pulls back deployed capital as conditions warrant. The remaining project token stays available for conversion at lower prices. Some teams configure Bootstrap to follow spot down, converting at new lower levels rather than waiting for recovery. Others configure it to pause and resume only on recovery. The team can request configuration changes at any time.
  </Accordion>

  <Accordion title="Does Bootstrap require an OTC deal or a loan for the quote token?">
    No. The project token converts to quote through the AMM as the market trades. The team starts with up to 100% project token, and the quote side fills in through trading flow. Some teams add quote to their vault later, but it is not required for the strategy to operate.
  </Accordion>

  <Accordion title="What happens after Bootstrap reaches the target ratio?">
    The vault auto-transitions to the [Flagship Strategy](/flagship), which manages the now-balanced inventory with volatility-adaptive width and tighter management around spot. It is optimized for ongoing fee capture rather than conversion. No manual handoff is required from the team.
  </Accordion>
</AccordionGroup>


# Commodities & Equities
Source: https://docs.arrakis.finance/commodities-equities



Tokenized commodities and equities give onchain exposure to a real-world asset. Two things have to hold for the token to be useful:

1. Its onchain price has to stay close to the real asset.
2. There has to be enough depth to trade it at size.

Default AMM mechanics deliver neither for an asset whose price is set off-chain.

Arrakis Pro runs both in one self-custodial vault. The issuer keeps custody through the vault NFT.

<Columns>
  <Card title="Accurate pricing" icon="crosshairs" href="/price-convergence">
    A commodity or equity is priced in an external market, not by onchain trading, so an unmanaged pool drifts from the real price and clears at stale values. Arbitrage corrects that drift for crypto-native assets, but not for these, where redemption is gated and liquidity is thin. [**Price Convergence**](/price-convergence) holds the pool to a configured reference feed instead.
  </Card>

  <Card title="Real depth" icon="layer-group" href="/flagship">
    An accurate price alone is not enough. Holders need to move size without heavy slippage for the token to work as collateral or as exposure. The vault runs an active concentrated strategy, typically [**Flagship**](/flagship), that keeps liquidity deep at the tracked price, the management behind any other Arrakis market.
  </Card>
</Columns>

## What's specific to equities

A tokenized equity trades 24/7, but the market it tracks does not. Through nights, weekends, and holidays the real price keeps moving, or gaps on the next open after earnings, while a static pool sits on the last print. That gap is an arbitrage the pool would hand to whoever trades first when the market reopens. Price Convergence realigns the pool to the equity reference as that happens, so the onchain price reflects the live mark rather than the stale one. Because the pool realigns on each rebalance, vaults for assets sensitive to market events are tuned to rebalance more frequently.

## What's specific to commodities

A commodity like gold trades almost around the clock on global markets, so the pricing gap is narrower than for equities. The same drift still applies whenever onchain trading lags the spot price, and Price Convergence keeps the pool on the spot feed. Onchain liquidity is the secondary market for the token: it sits alongside whatever redemption or backing process the issuer runs, giving holders a way to trade in and out without going through redemption.

## How Arrakis fits

The asset runs in a self-custodial vault with Price Convergence configured against the right feed and an active strategy managing depth.

| Asset type                                  | Reference source         |
| ------------------------------------------- | ------------------------ |
| Tokenized commodities (gold and others)     | External spot price feed |
| Tokenized equities (single stocks, indices) | Equity price feed        |

The same hook serves other externally-priced assets, including non-USD (FX) stablecoins and tokenized treasuries. See [**Price Convergence**](/price-convergence) for the full reference list and mechanism.

## Considerations

<Columns>
  <Card title="The reference feed is the trust anchor.">
    The pool tracks whatever the configured feed reports, so the feed's accuracy and integrity determine how well the token tracks. Choosing the feed is part of the setup.
  </Card>

  <Card title="Tracking follows the rebalance cadence.">
    The pool realigns on each rebalance, not continuously, so tracking is as tight as the rebalance schedule. Assets sensitive to market events are configured to rebalance more often.
  </Card>
</Columns>

## Getting started

Arrakis deploys and configures the vault on the issuer's behalf, including the feed and strategy, then transfers the vault NFT to the issuer's multisig. The team keeps custody throughout.

## FAQ

<AccordionGroup>
  <Accordion title="Does the token have to be redeemable for the underlying to be market-made?">
    No. Arrakis provides the onchain secondary market, deep liquidity to trade the token against its quote, independent of how the issuer handles redemption or backing. Holders get a way to enter and exit onchain whether or not they ever redeem for the physical commodity or the underlying share.
  </Accordion>

  <Accordion title="Where does the reference price come from?">
    From a configured external feed: a commodity spot feed or an equity price feed, sourced through providers such as Chainlink or Redstone, or another feed appropriate to the asset. Price Convergence reads it on each rebalance. See [**Price Convergence**](/price-convergence) for supported feed types.
  </Accordion>

  <Accordion title="Does this only cover commodities and equities?">
    No. The same mechanism serves any externally-priced asset, including non-USD (FX) stablecoins and tokenized treasuries. The [**Price Convergence**](/price-convergence) page has the full set. Tokens that accrue value through yield are covered on [**Yield-Bearing Assets**](/yield-bearing-assets-and-rwas).
  </Accordion>
</AccordionGroup>


# Dynamic Fees
Source: https://docs.arrakis.finance/dynamic-fees



Every AMM pool charges a fee on each trade, and most pools charge a single fixed fee. A fixed fee is always a compromise. Set it too low and the pool leaks value to arbitrageurs when the market moves quickly. Set it too high and it suppresses the everyday volume that generates income. Real markets are not static: volatility rises and falls, volume surges, and inventory drifts away from balance, so the fee that was right an hour ago is rarely right now.

Dynamic Fees is a feature of the Arrakis Hook on Uniswap v4 that adjusts the pool's trading fee in real time based on live market conditions. Arrakis's market-making system raises the fee when volatility, a volume surge, or inventory imbalance calls for it, capturing more on the flow that costs LPs the most, and lowers it when the market is calm and balanced to attract volume and stay competitive. The result is higher fee income and less adverse selection than a static fee can deliver, with no action required from the team.

## How it works

Dynamic Fees runs as part of the vault's active management. Arrakis's market-making system reads live signals for the pool, computes the fee that fits current conditions, and the Arrakis Hook on Uniswap v4 applies it onchain. The fee moves gradually, so the pool adapts continuously without sudden jumps that would unsettle traders or invite gaming.

```mermaid theme={null}
flowchart LR
    Signals[Live signals: volatility, volume, inventory imbalance] --> MM[Arrakis market-making system computes the fee]
    MM --> Hook[Arrakis Hook on Uniswap v4 applies it onchain]
    Hook --> Pool([Pool fee adapts gradually])
```

The fee responds to two main conditions:

<Card title="Volatility and volume surges">
  When realized volatility or trading volume spikes above its normal range, the fee rises. Sharp moves and bursts of activity are when liquidity is most exposed to arbitrage and impermanent loss, so a higher fee captures more from that flow and compensates LPs for the risk. As the market calms, the fee falls back to attract volume.
</Card>

<Card title="Inventory imbalance">
  As the pool's inventory drifts away from balance, the fee adjusts by side to defend it. It becomes more expensive to trade in the direction that deepens the imbalance and cheaper in the direction that restores it.
</Card>

## Directional fees

Because the hook can price each side of the pool independently, Dynamic Fees can be asymmetric. A common configuration makes it more expensive to sell the token the pool already holds in excess, nudging flow toward rebalancing the inventory rather than worsening it, the same maker-taker logic market makers use on order books.

## Configuration

Dynamic Fees runs alongside the active strategy, most commonly [**Flagship**](/flagship). Arrakis's market-making system manages the fee, so the team does not set or adjust it trade by trade. The fee is not an onchain parameter the team configures: a team opts into Dynamic Fees by accepting the underlying pool the Arrakis Hook runs on. The vault stays self-custodial throughout.

## Considerations

<Columns>
  <Card title="Requires the Arrakis Hook on Uniswap v4.">
    Dynamic Fees is part of the Arrakis Hook and runs on the chains where Arrakis operates Uniswap v4 vaults. Pools on other venues use a static fee tier.
  </Card>

  <Card title="Managed by Arrakis, not set by the team.">
    The fee is computed and updated by Arrakis's market-making system from live signals. It is not an onchain setting the team controls; the team opts in by accepting the pool the Arrakis Hook runs on.
  </Card>

  <Card title="Most valuable in active markets.">
    The benefit comes from adapting to changing conditions. In a consistently quiet, balanced market the fee simply sits near its baseline.
  </Card>
</Columns>

## FAQ

<AccordionGroup>
  <Accordion title="Who decides the fee at any given moment?">
    Arrakis's market-making system computes the fee from live signals (volatility, volume, and inventory), and the Arrakis Hook on Uniswap v4 applies it onchain.
  </Accordion>

  <Accordion title="Does this work on any DEX?">
    No. Dynamic Fees relies on the Arrakis Hook on Uniswap v4, so it runs on the chains where Arrakis operates v4 vaults. On other venues the vault uses a static fee tier.
  </Accordion>

  <Accordion title="Can it run alongside Price Convergence?">
    Yes. Both are enabled by the Arrakis Hook on Uniswap v4. Dynamic Fees manages the trading fee while [**Price Convergence**](/price-convergence) aligns the pool price to an external reference, and they can run together on the same vault.
  </Accordion>
</AccordionGroup>


# Flagship
Source: https://docs.arrakis.finance/flagship



Arrakis Pro's Flagship strategy actively manages onchain liquidity for mature token markets so deep liquidity around the spot price is automatically maintained as market conditions change. Token issuers can minimize slippage and continue to earn fees without manual rebalancing.

The Flagship Strategy is mostly used by teams undergoing or having done a Token Generation Event, assuming they already have a certain percentage of quote assets (for example USDC or ETH) available to pair with their project token. If the team does not have any quote assets yet, they should usually start with the [Bootstrap Strategy](/bootstrap) first and then later transition into the Flagship strategy.

The strategy adapts continuously to market volatility. In calm markets, liquidity tightens around the spot price to maximize fee capture. As volatility rises, the strategy widens its positions and reduces exposure to protect capital. These shifts happen automatically.

## How it works

The team deposits its tokens into an Arrakis vault on a supported DEX and chain and configures the target inventory ratio (typically 50/50).

The strategy continuously measures market conditions and deploys liquidity across multiple concentrated positions around the spot price. The position layout adapts to current volatility:

| Market condition       | How the strategy responds                                                                                    |
| ---------------------- | ------------------------------------------------------------------------------------------------------------ |
| 🟢 Calm                | Concentrates liquidity tightly around the spot price, providing the best trade execution while earning fees. |
| 🟡 Moderate volatility | Widens its positions to protect the vault's inventory.                                                       |
| 🔴 High volatility     | Widens positions further to reduce exposure and protect the vault's inventory.                               |

The strategy builds the position from up to three range types:

<Columns>
  <Card title="Base Range" icon="arrows-left-right">
    A wide range holding the core liquidity, so large orders trade with minimal price impact.
  </Card>

  <Card title="Bootstrapping Range" icon="scale-balanced">
    A narrow, limit-order-like range that works inventory back toward the target ratio.
  </Card>

  <Card title="Mid Range" icon="bullseye">
    A tight range at the spot price that adds deep liquidity for average-size orders in calm conditions.
  </Card>
</Columns>

The strategy rebalances automatically on three triggers: when the price moves beyond a threshold, when the inventory ratio drifts from target, or when sustained volatility calls for wider or tighter positioning.

<Note>
  **TWAP protection.** All rebalances are checked against a TWAP (time-weighted average price) that blocks responses to short-lived price spikes, protecting the vault against price manipulation and preventing the strategy from reacting to noise.
</Note>

When inventory drifts from target (typically because the market has moved through most of the deployed liquidity in one direction), the strategy widens positions and pulls back deployed capital. The remaining inventory stays protected while organic flow brings the ratio back toward target.

The team can pause, reconfigure, or withdraw at any time.

## Considerations

<Card title="Performance scales with trading volume.">
  Flagship earns fees from trades that pass through its liquidity. In low-volume markets, fees accrue more slowly.
</Card>

<Card title="The strategy reduces but does not eliminate impermanent loss.">
  Flagship widens positions and pulls back capital during volatile periods, which limits exposure to large directional moves. LP positions still produce impermanent loss through large moves relative to holding the underlying tokens directly. The strategy mitigates the magnitude rather than removing the risk.
</Card>

<Card title="TWAP protection slows reaction to fast moves.">
  The same check that blocks rebalances during suspicious price spikes can also slightly delay responses to genuine fast moves. This tradeoff favors safety over speed.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="How does Flagship adapt to changing volatility?">
    The strategy continuously measures market volatility and adjusts its positioning as conditions change in a sustained way. It responds to shifts that hold up over time, not short-term spikes, so it does not react to every brief volatility burst.
  </Accordion>

  <Accordion title="Does Flagship require active oversight?">
    No. Once the vault is configured, the strategy operates fully automatically, without the team's intervention. The team can monitor performance through the Arrakis Pro dashboard and pause, reconfigure, or withdraw at any time.
  </Accordion>

  <Accordion title="What happens to liquidity during a market crash?">
    The strategy widens positions and reduces deployed capital as volatility rises. Volatile two-way price action is the worst case for any concentrated LP strategy. Flagship dampens that exposure but does not remove it: LPs still take some impermanent loss when prices move sharply.
  </Accordion>

  <Accordion title="Can the strategy's activity be verified onchain?">
    Yes. The vault's positions, fees earned, and inventory are visible onchain at any time and can be viewed on the Arrakis Pro dashboard.
  </Accordion>

  <Accordion title="How does this compare to running a Uniswap position manually?">
    A self-managed full-range position spreads capital across the entire price curve, earning a small share of fees from every trade, and most of the capital is never used productively. A self-managed concentrated position earns more fees per dollar when the price is in range, but stops earning when the price moves out and requires manual rebalancing to restore. Flagship combines concentrated liquidity with automated rebalancing: it captures fees consistently as the market moves, with no need to monitor or act. The tradeoff is that automation requires trust in the strategy's logic, which is why Flagship operates within bounded risk levels and uses TWAP protection on every rebalance.
  </Accordion>
</AccordionGroup>


# Price Convergence
Source: https://docs.arrakis.finance/price-convergence



The value of RWAs and other externally-priced assets is determined outside of DeFi. A tokenized commodity tracks a spot price, a tokenized treasury tracks its NAV, a non-USD stablecoin tracks a forex rate.

An AMM pool only updates when someone trades it, so the pool price drifts from the asset's true value. For crypto assets, arbitrageurs naturally close that gap. For externally-priced assets they do not: redemption queues are long, liquidity is thin, and the risk-adjusted return isn't there. That leaves the issuer to correct the drift manually.

Price Convergence is a Uniswap v4 hook that aligns the pool price with an external reference automatically. On each rebalance it reads the asset's reference price and updates the pool's internal price to match, in the same atomic transaction. The correction happens inside the rebalance, not through an open market trade, so there is no window for an arbitrageur to trade against it and no dependence on arbitrage to correct the price. Convergence happens at each rebalance, so tracking is as tight as the rebalance cadence.

## How Price Convergence works

Price Convergence replaces manual correction with protocol-level logic. The Arrakis vault runs an active strategy that rebalances the position over time. On each rebalance, the Price Convergence hook reads the asset's reference price (NAV), updates the pool's internal price to match, and redeploys liquidity around the corrected price.

```mermaid theme={null}
flowchart LR
    Ref[External reference<br/>NAV / spot / forex / exchange rate]
    Ref -- "read on each rebalance" --> Hook[Price Convergence hook]
    Hook --> Update[Update pool internal price<br/>atomically]
    Update --> Redeploy[Redeploy liquidity<br/>around the reference]
    Redeploy --> Pool([Pool tracks<br/>real-world value])
```

Price Convergence is made possible because Uniswap v4 exposes programmable hooks that modify pool behavior at the protocol level. Earlier AMM designs have no equivalent, which is why externally-priced assets have historically depended on manual maintenance.

## Reference sources by asset type

The hook reads whatever reference fits the asset. The common mappings:

| Asset type                                | Reference source             |
| ----------------------------------------- | ---------------------------- |
| Tokenized commodities (such as gold)      | External spot price feed     |
| Tokenized treasuries and NAV-based credit | Onchain NAV feed             |
| Tokenized equities                        | Equity price feed            |
| Non-USD (FX) stablecoins                  | Forex rate feed              |
| Yield-bearing assets                      | ERC-4626 vault exchange rate |

## Ways teams use it

<Columns>
  <Card title="Continuous reference tracking">
    For RWAs and assets that should always reflect an external value, Price Convergence keeps the pool aligned to the reference on every rebalance. The onchain price tracks the underlying continuously, with no manual maintenance.
  </Card>

  <Card title="Price alignment at launch">
    For onchain token launches, the DEX price can drift from a CEX listing price, leaking value to arbitrageurs as they close the gap. Price Convergence aligns the pool to the CEX price from the moment trading opens, the pattern used with [**Uniswap CCA**](/uniswap-cca).
  </Card>
</Columns>

## Requirements and trust model

<Columns>
  <Card title="A reliable reference feed.">
    Price Convergence is only as accurate as the source it reads. Supported sources include Chainlink, Pyth, and Redstone price feeds, onchain NAV contracts, and ERC-4626 exchange rates. These are defined by the team upfront.
  </Card>

  <Card title="The reference feed is the trust anchor.">
    The pool tracks whatever the configured feed reports, so the accuracy and integrity of that feed determine how well Price Convergence works.
  </Card>

  <Card title="Uniswap v4.">
    The hook requires Uniswap v4. It runs on the chains where Arrakis operates v4 vaults: Ethereum, Base, Arbitrum, Optimism, Unichain, and Ink.
  </Card>
</Columns>

## FAQ

<AccordionGroup>
  <Accordion title="Is Price Convergence an oracle?">
    No. Price Convergence consumes a price feed from an oracle, such as Chainlink, an onchain NAV contract, or an ERC-4626 exchange rate, and acts on it by updating the pool's internal price to match during a rebalance.
  </Accordion>

  <Accordion title="Does moving the pool price let arbitrageurs extract value?">
    No. A manual correction is a visible trade that front-runners can exploit. Price Convergence updates the price atomically inside the rebalance, with no open window to trade against, so the correction does not leak value the way manual trading does.
  </Accordion>

  <Accordion title="How often does the pool converge to the reference?">
    Convergence happens on each rebalance, so the cadence follows the strategy's rebalance frequency. Assets that need tight tracking are configured to rebalance more often. The reference feed and the rebalance schedule together determine how closely the pool tracks the real-world price.
  </Accordion>

  <Accordion title="Which chains support Price Convergence?">
    The chains where Arrakis runs Uniswap v4 vaults: Ethereum, Base, Arbitrum, Optimism, Unichain, and Ink.
  </Accordion>
</AccordionGroup>


# Stablecoin Issuers
Source: https://docs.arrakis.finance/stablecoin-issuers



Stablecoin issuers control their primary market end to end: mint, redeem, and the rails behind them. The onchain pool where most holders convert is different. While it determines how usable the token is, it is often left unmanaged. A thin or stale pool means holders exit below fair value, and integrators often shy away.

Arrakis Pro manages the onchain secondary market liquidity for stablecoin issuers. Vaults hold concentrated liquidity at the token's reference rate, whether that is a USD peg, a live FX rate, or a yield-accruing exchange rate, and the strategy rebalances automatically as that rate moves. The issuer funds the pool from treasury and keeps custody of it throughout.

## The pool sets the token's real price

Holders judge a stablecoin by the price they can actually convert at, and integrators underwrite the same number. A pool that clears large sells at 0.995 sets the token's real price at 0.995, regardless of what the reserves say.

| Who reads the pool      | What they read                                                          |
| ----------------------- | ----------------------------------------------------------------------- |
| Lending markets         | The depth they can liquidate through, when sizing collateral parameters |
| Aggregators and routers | Price impact at size, which decides where flow routes                   |
| Holders and treasuries  | Whether size clears at the reference, on demand                         |

For crypto-backed designs the pool also carries liquidation flow, so its depth is what liquidations clear through. With Arrakis, the strategy holds depth at the reference rate, two-sided for USD and FX pools and weighted to the exit side for yield-bearing designs whose buyers mint directly. That depth is always verifiable onchain by anyone evaluating the token.

Most issuers rent this depth instead: emissions, gauge incentives, and points programs pay external LPs to provide it. Rented depth is a recurring expense that scales with the incentive budget, and it leaves when the program ends. With Arrakis, vault inventory is the issuer's own: it stays, it recycles through the primary market, and its cost is the capital commitment rather than an emissions schedule.

## Different stablecoins track different references

A stablecoin pool has to hold depth at the right price, and what "right" means depends on the type of stablecoin.

| Stablecoin type           | The pool must track                              | How the strategy tracks it                                                                      |
| ------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
| USD stablecoins           | Parity with USDC or USDT                         | Concentrated liquidity around parity, with [**Dynamic Fees**](/dynamic-fees)                    |
| Non-USD (FX) stablecoins  | The live FX rate against the quote asset         | [**Price Convergence**](/price-convergence) realigns the pool to a forex feed on each rebalance |
| Yield-bearing stablecoins | An exchange rate that drifts up as yield accrues | [**Yield-Bearing Asset Strategy**](/yield-bearing-asset) repositions along the yield curve      |

**USD stablecoins** quote against USDC or USDT at a fixed parity reference. The strategy concentrates inventory around parity, so capital sits where trades actually clear, and [**Dynamic Fees**](/dynamic-fees) adjust the pool's fee to conditions: higher when volatility, a volume surge, or a growing inventory imbalance calls for it, lower when the market is calm. The fee can move independently per side, so trading in the direction that deepens an imbalance costs more than trading in the direction that restores it.

**Non-USD stablecoins** have no fixed peg against their quote asset. A EUR, CHF, or JPY stablecoin trades against USDC at a rate the currency market moves through the trading week and gaps across weekends and holidays, and a static position is an open offer for arbitrageurs to trade at yesterday's rate. Arrakis' [**Price Convergence**](/price-convergence) reads a forex feed and updates the pool price inside the rebalance, so the pool requotes to the current rate instead of paying arbitrageurs to correct it.

**Yield-bearing stablecoins** appreciate against their quote as yield accrues, so liquidity has to follow the exchange rate upward. The [**Yield-Bearing Asset Strategy**](/yield-bearing-asset) tracks the rate through the token's ERC-4626 vault and is covered in full on [**Yield-Bearing Assets**](/yield-bearing-assets-and-rwas).

The categories combine: a stablecoin can be both non-USD and yield-bearing, and the reference setup for a combined case is confirmed per asset.

## Pool inventory is working capital, not reserves

The capital in the pool is not the reserve that backs outstanding supply. A fiat-backed reserve sits in cash and short-term instruments, and regulated issuers often cannot deploy it into an AMM pool at all.

|              | Reserves                        | Pool inventory                 |
| ------------ | ------------------------------- | ------------------------------ |
| **Job**      | Back outstanding supply at par  | Hold conversion depth onchain  |
| **Sized to** | Outstanding supply              | Target depth and expected flow |
| **Deployed** | Cash and short-term instruments | Onchain, in the issuer's vault |

The issuer deposits stablecoin and quote asset into a self-custodial vault and holds the vault NFT that controls it. The strategy manages the position within its configured parameters, and the issuer can pause, reconfigure, or withdraw at any time.

## Inventory recycles through mint and redeem

Flow in a young stablecoin pool is usually one-sided: recipients sell the stablecoin for the quote asset, the position accumulates stablecoin, and quote-side depth drains. Directional [**Dynamic Fees**](/dynamic-fees) slow the drain by pricing against the imbalance, but they do not reverse it. Without a replenishment loop, exit depth stops.

The strategy manages inventory within configured bands, and accumulated stablecoin recycles through the primary market: redeem the stablecoin, convert the proceeds to the quote asset, redeploy onchain.

```mermaid actions={false} theme={null}
flowchart TD
    A[Holders sell the stablecoin into the pool] --> B[Position accumulates stablecoin]
    B --> C[Redeem through the primary market]
    C --> D[Proceeds convert to the quote asset]
    D --> E[Quote-side depth replenished]
    E --> A
```

The issuer runs the loop through its own mint and redeem. Where an onchain redemption path exists (a PSM for a crypto-backed design, an ERC-4626 vault for a yield-bearing one, or a canonical bridge), the loop stays onchain and runs faster.

## Considerations

<Card title="Tracking is as tight as the feed and the cadence.">
  A non-USD pool tracks the configured forex feed at each rebalance, so tracking quality is set by the feed and the rebalance schedule. Forex feeds typically update on a deviation threshold and a heartbeat rather than tick by tick. Tighter tracking takes a faster feed and more frequent rebalances. A reference feed has to exist for the currency pair, and confirming coverage for less-traded currencies is part of discovery.
</Card>

<Card title="Price Convergence and Dynamic Fees require Uniswap v4.">
  Both run as v4 hooks on the chains where Arrakis operates Uniswap v4 vaults, listed on [**Price Convergence**](/price-convergence). Pools on other venues run an active strategy with a static fee.
</Card>

<Card title="The quote leg is a currency position.">
  A non-USD pool holds part of its inventory in USDC or USDT, an open FX exposure for a treasury that accounts in the token's currency. Whether and how to hedge it is a treasury decision made alongside sizing.
</Card>

<Card title="The pool makes the peg tradable, not credible.">
  Depth at the reference rate gives holders an exit at fair value. It is not what makes the token worth that value: solvency comes from reserves and redemption. Under extreme one-way flow the position can exhaust quote-side inventory and sit one-sided until recycling restores it.
</Card>

<Card title="Recycling runs at the speed of the issuer's rails.">
  If redemption settles in days over fiat rails, the pool needs enough standing depth to absorb flow across that window, and sizing accounts for it.
</Card>

## Getting started

<Steps>
  <Step title="Discovery">
    Currencies, chains, and venues, target depth and spread, expected flow, and funding. Arrakis analyzes any existing pools and simulates the improvement.
  </Step>

  <Step title="Reference setup">
    Quote assets confirmed, typically USDC or USDT. Non-USD stablecoins get a forex feed configured for [**Price Convergence**](/price-convergence), and yield-bearing stablecoins get the ERC-4626 interface confirmed for the [**Yield-Bearing Asset Strategy**](/yield-bearing-asset).
  </Step>

  <Step title="Funding">
    The issuer deposits stablecoin and quote asset into the vault.
  </Step>

  <Step title="Live management">
    The strategy takes over rebalancing and inventory management. The vault can be paused, reconfigured, or withdrawn at any time.
  </Step>
</Steps>

<Card title="Integrate Arrakis" icon="laptop" href="https://qxqhpatmzz7.typeform.com/to/IZdNgmmM?typeform-source=docs.arrakis.finance">
  Talk to the Arrakis team about your stablecoin.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="We are a regulated issuer and cannot deploy capital into DeFi. Can we still have onchain liquidity?">
    The constraint is common among licensed e-money and bank-affiliated issuers. Pool inventory is never the reserve, and setups for constrained issuers are scoped with the Arrakis team during discovery.
  </Accordion>

  <Accordion title="Which pools should we launch first?">
    The quote asset is typically USDC or USDT, with the first pool on the chain where the token's distribution is strongest and additional pairs or chains added as flow justifies them. Each additional pool splits the same inventory, so depth per pool falls as the count rises.
  </Accordion>

  <Accordion title="What happens during a depeg or redemption stress?">
    Depeg behavior depends on the strategy. The [**Yield-Bearing Asset Strategy**](/yield-bearing-asset), for example, stops repositioning when the pool price diverges far from its tracked exchange rate, so it does not rebalance through a stressed price, and the position can sit out of range until the gap closes. Across all configurations the pool does not buy without limit to defend a price: conversion depth is the pool's job, and solvency is the reserve's.
  </Accordion>

  <Accordion title="We also have a governance or utility token. Is that the same setup?">
    No. A governance or utility token trades like any project token: [**Bootstrap**](/bootstrap) for the launch, [**Flagship**](/flagship) for ongoing management, covered on [**Token Issuers**](/token-issuers). Both can run alongside the stablecoin vaults under the same issuer.
  </Accordion>
</AccordionGroup>


# Supported Chains
Source: https://docs.arrakis.finance/supported-chains



Arrakis Pro supports Ethereum, major EVM-compatible chains, Hyperliquid, and Solana.

| Chain       | DEXs available                   |
| :---------- | :------------------------------- |
| Ethereum    | Uniswap v3, Uniswap v4           |
| Base        | Uniswap v4, Aerodrome            |
| Arbitrum    | Uniswap v4                       |
| Optimism    | Uniswap v4, Velodrome            |
| BNB Chain   | PancakeSwap v3 and v4 (Infinity) |
| Unichain    | Uniswap v4                       |
| Ink         | Uniswap v4                       |
| Solana      | PropAMM                          |
| Hyperliquid | Hyperliquid                      |

## Adding a chain

The modular architecture supports any chain where a compatible concentrated-liquidity DEX runs. For a chain not listed, [contact us](https://arrakis.finance/contact).


# Supported DEXs
Source: https://docs.arrakis.finance/supported-dexs



| <br />**DEX** | **Modules**       | **Chains**                                                   |
| :------------ | :---------------- | :----------------------------------------------------------- |
| Uniswap       | v3, v4            | Ethereum, Base, Arbitrum, Optimism, BNB Chain, Unichain, Ink |
| Aerodrome     | Slipstream        | Base                                                         |
| Velodrome     | Slipstream        | Optimism                                                     |
| PancakeSwap   | v3, v4 (Infinity) | BNB Chain                                                    |

## **Hyperliquid**

Arrakis market makes on Hyperliquid for asset issuers across perps and spot. Hyperliquid uses a delegated model rather than the vault-and-module model: the issuer brings capital and Arrakis manages execution.

## **Solana**

On Solana, Arrakis Pro makes markets on Jupiter and Titan aggregators through Hadron PropAMM model rather than the EVM vault-and-module model.


# Token Issuers
Source: https://docs.arrakis.finance/token-issuers



Token issuers of crypto-native assets (e.g. SYRUP, MORPHO, etc) need deep, persistent onchain liquidity from the moment their token goes live. The default approaches break down at scale: full-range liquidity leaves most capital sitting where no trade ever happens, manually managed concentrated positions are operationally unsustainable for teams, and incentive-driven LPs rotate out the moment emissions stop. The result is thin depth, fee revenue leaking to external LPs, and price impact that erodes trader experience and volume.

Arrakis Pro is the active liquidity layer for token issuers. Self-custodial vaults run automated strategies that adapt as the token matures, and the team keeps custody throughout. Concentrated active management has historically delivered approximately 4x deeper liquidity per dollar deployed than full-range positions and 3x higher fee capture. Across live deployments, Arrakis manages over 100 token issuers and has facilitated more than \$5B in onchain volume.

## How protocol-owned liquidity (POL) is typically deployed

Token issuers typically deploy protocol-owned liquidity in one of three ways, with different tradeoffs across capital efficiency, operational overhead, and ongoing performance.

|                          | Full-range POL    | Manual concentrated LP | Arrakis Pro                 |
| ------------------------ | ----------------- | ---------------------- | --------------------------- |
| **Capital efficiency**   | Most capital idle | Drifts out of range    | Always at the trading price |
| **Operational overhead** | None              | Constant, hands-on     | None for the team           |
| **Fee capture**          | Low               | Variable               | Maximized                   |
| **Rebalancing**          | None              | Manual                 | Automated                   |
| **Lifecycle adaptation** | None              | Manual                 | Automatic                   |

## Strategies

Arrakis Pro runs multiple strategies, each built for a specific use case. They transition automatically as the token matures.

<Columns>
  <Card title="Bootstrap Strategy" icon="rocket" href="/bootstrap">
    For TGE and launches with skewed inventory (typically up to 95% project token). Accumulates ETH or USDC from buyer demand as the market trades through the position, avoiding the need for OTC deals or large quote-side treasury commitments. Auto-transitions to Flagship once the target inventory ratio is reached.
  </Card>

  <Card title="Flagship Strategy" icon="anchor" href="/flagship">
    For ongoing post-launch active management. Concentrates the position around spot in calm markets and widens the range as volatility rises. Dynamic fees adjust to market conditions. The default strategy after Bootstrap completes.
  </Card>

  <Card title="Treasury Diversification Strategy" icon="coins" href="/treasury-diversification">
    For gradual conversion of project token into ETH or stablecoins over time. Passive concentrated liquidity around spot converts the project token as the market trades through, avoiding the price impact of market-selling or OTC discounts. Useful for treasury management once the token has matured.
  </Card>
</Columns>

If your token accrues value through yield (liquid staked tokens, yield-bearing stablecoins, tokenized treasuries), see [**Yield-Bearing Assets**](/yield-bearing-assets-and-rwas).

## Features

Hooks are Uniswap v4 features that add capability on top of any strategy. They are configured at vault deployment and run alongside the active strategy.

* [**Price Convergence**](/price-convergence): Holds the pool price to an external reference feed. Used primarily by assets that track an off-chain price, such as RWAs.
* [**Dynamic fees**](/dynamic-fees): Adjust the fee tier to volatility and trading momentum, capturing more on volatile flow and less on quiet flow.

## Launchpad integrations

For projects launching through a specific launchpad, Arrakis has dedicated migration or pre-deployment integrations.

* [**Uniswap CCA**](/uniswap-cca): Migrates the CCA-seeded Uniswap v4 full-range position into an actively managed Arrakis vault in a single atomic transaction. Teams can engage before the auction or migrate after it completes.
* [**Aerodrome Ignition**](/aerodrome-ignition): Pre-launch vault deployment on Base. Runs Bootstrap through Epoch 1 to accumulate quote-side reserves as buyers enter the pool, then auto-transitions to Flagship through Epoch 2 to maintain depth as mercenary LPs rotate out.
* [**Binance Alpha**](/binance-alpha): Active management of the official Alpha pool through the volatile launch window. Flagship-led, adapted to the program's launch requirements.

## Integration path

Pre-TGE teams typically engage 2-4 weeks ahead of TGE. Teams with existing pools can onboard at any time.

<Steps>
  <Step title="Discovery">
    Initial conversation with the Arrakis team to discuss the token, launch profile (pre-TGE) or current pool state (post-TGE), and the strategy, hook, and launchpad combination that fits. Where useful, Arrakis runs an onchain liquidity analysis of the existing setup and simulates the improvement.
  </Step>

  <Step title="Configuration">
    Vault parameters confirmed: pool, fee tier, tick range, dynamic fee config, strategy schedule, optional hooks. For launchpad launches, launchpad-specific setup (pool gauge creation, voter contract whitelisting, and so on) runs in parallel.
  </Step>

  <Step title="Deployment">
    Arrakis deploys the vault on the chosen DEX and chain. Existing positions can be migrated atomically where the launchpad supports it (for example, the Uniswap CCA migration helper).
  </Step>

  <Step title="Self-custody">
    The vault NFT is owned by the team's multisig or MPC wallet. The team owns the vault for its full lifecycle.
  </Step>

  <Step title="Active management begins">
    The chosen strategy begins automatically. The team can pause, reconfigure, or withdraw at any time. Strategy transitions (for example, Bootstrap → Flagship) run automatically based on configured triggers.
  </Step>
</Steps>

<Card title="Integrate Arrakis" icon="laptop" href="https://qxqhpatmzz7.typeform.com/to/IZdNgmmM?typeform-source=docs.arrakis.finance">
  Talk to the Arrakis team about your TGE or existing token.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="How much capital should we deploy?">
    Sizing depends on the token, the trading depth target, expected volume, and the chosen strategy. Pre-launch coordination includes a depth analysis to determine recommended deployment for the specific launch. Because Arrakis concentrates liquidity around the trading price, the same trading depth can be achieved with roughly 25% of the capital that a full-range position would require.
  </Accordion>

  <Accordion title="We already have a Uniswap or Aerodrome position deployed manually. Can we migrate?">
    Yes. For Uniswap CCA positions, migration is atomic through the dedicated helper contract (see [Uniswap CCA](/uniswap-cca)). For other manually managed v3 / v4 / Slipstream positions, the typical path is to withdraw the existing position and deposit into a freshly deployed Arrakis vault. Coordination with the Arrakis team determines the path based on the current setup, including options for zero-downtime migration where significant prefunding is possible.
  </Accordion>

  <Accordion title="Can we change strategy as our token matures?">
    Yes. Strategy parameters and the active strategy itself are reconfigurable at any time. Common transitions include Bootstrap → Flagship after initial inventory rebalances, or Flagship → Treasury Diversification when the team decides to convert project token to quote. Reconfiguration runs as an authenticated call from the vault NFT holder.
  </Accordion>

  <Accordion title="Who controls the funds throughout?">
    The team. Arrakis vaults are self-custodial. The team holds the vault NFT, which represents ownership of the underlying position. Arrakis runs the active management strategy, and changes to the vault's core parameters are subject to a two-day timelock, so the team always has time to review or exit. The team can pause, reconfigure, or withdraw at any time.
  </Accordion>

  <Accordion title="What if we are not sure which strategy is right for us?">
    The discovery step covers this. For most launches the strategy is determined by the launch profile: a TGE with skewed inventory points to Bootstrap, an existing balanced pool to Flagship, and a yield-accruing token to the Yield-Bearing Asset Strategy. For launches through a specific launchpad, the integration page covers the recommended setup (see [Uniswap CCA](/uniswap-cca), [Aerodrome Ignition](/aerodrome-ignition)).
  </Accordion>

  <Accordion title="Can we run more than one strategy at once?">
    Yes. Teams often run several vaults in parallel, each with its own strategy, for example a Flagship vault for ongoing market making alongside a Treasury Diversification vault converting part of the treasury. Each vault is independent and self-custodial.
  </Accordion>
</AccordionGroup>


# Treasury Diversification
Source: https://docs.arrakis.finance/treasury-diversification

Gradually convert a project's treasury into stablecoins or ETH using organic market demand, avoiding the price impact of selling and the discount of an OTC deal.

Arrakis Pro's Treasury Diversification strategy allows token issuers to gradually convert project tokens into stablecoins or ETH over time, avoiding negative price impact, using organic market demand instead of market-selling or OTC discounts.

The strategy deploys passive concentrated liquidity around the token's spot price. Conversions happen as organic buying volume routes through the DEX liquidity, never by initiating sales.

Treasury Diversification differs from [Bootstrap](/bootstrap) in what happens to the converted quote and how it ends. Bootstrap deploys the full inventory and keeps the quote it captures in the pool, spread around the price, building toward a balanced position that graduates to Flagship near a 50/50 ratio. Treasury Diversification releases the project token to the market in small batches and removes the quote from the pool as it is captured, holding it in the vault. It runs to a defined end, converting the targeted project token fully into the quote asset rather than graduating to ongoing management.

## How it works

The team deposits a number of its project tokens into an Arrakis vault on a supported DEX and chain.

Those tokens are deployed as single-sided concentrated liquidity across multiple positions around the spot price. Small positions sit close to the market for gradual conversion with minimal local price impact. Larger positions sit further out to capture upside price spikes. As the market trades through any position, that portion of tokens converts into the quote asset, which is removed from the pool and held in the Arrakis vault. The vault repositions automatically as spot moves, keeping the configured distribution intact, so each new market buy converts some project tokens into the quote asset.

The team can pause, reconfigure, or withdraw at any time.

## Considerations

<Card title="Pace is bounded by market activity.">
  Conversions only happen when the market trades through the positions. In a low-volume market, diversification takes longer. Configuring the strategy more aggressively converts faster but at lower average prices.
</Card>

<Card title="Limit orders follow market price.">
  Limit orders can be configured to follow the market price and fill at average prices on upside movements.
</Card>

<Card title="The position is visible onchain.">
  A sophisticated observer could read the position distribution from the vault. For most teams this is a positive: the community can verify exactly what the strategy is doing.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="Does the strategy negatively impact the token price?">
    No. The liquidity is passive: it sits in the AMM and converts only when the market trades through it, never by initiating sales. Position sizes near spot are kept small, so any single conversion is tiny relative to market volume. Larger positions further out capture upside spikes when they happen, locking in higher prices during rallies.
  </Accordion>

  <Accordion title="How long does diversification realistically take?">
    Diversification time depends on the configuration and organic trading volume. In a moderately liquid market, conversion plays out over weeks to a month, not days. More aggressive configurations fill faster at lower average prices, while slower configurations preserve prices but take longer.
  </Accordion>

  <Accordion title="What happens if the market drops mid-conversion?">
    Behavior during drawdowns is configurable. Some teams configure the strategy to follow spot down, converting small amounts at new lower price levels rather than waiting indefinitely. Average-priced conversion can outperform sitting on the sidelines if the market does not recover. Others configure the strategy to pause when prices fall below a certain threshold and resume only on recovery. The team can request configuration changes at any time.
  </Accordion>

  <Accordion title="How is this different from a CoW Protocol TWAP or an OTC?">
    A TWAP market-sells the tokens on a fixed schedule, taking whatever price the market gives at each interval and taking existing liquidity from the market. An OTC deal converts at a single negotiated discount to spot in a private transaction. Treasury Diversification is passive and adds liquidity instead: liquidity is deployed in an AMM and converts only when the market trades through it. It takes longer than a TWAP and is less predictable than an OTC sale, but avoids the price impact of market-selling and the discount of a private deal.
  </Accordion>

  <Accordion title="Can teams change the configuration after deployment?">
    Yes. The position distribution, allocation targets, and pace are all reconfigurable. The vault is the team's, and the strategy parameters can be adjusted as market conditions evolve.
  </Accordion>
</AccordionGroup>


# Uniswap CCA
Source: https://docs.arrakis.finance/uniswap-cca



Uniswap's [Continuous Clearing Auction (CCA)](https://cca.uniswap.org/) bootstraps onchain liquidity at the close of a token auction, seeding a Uniswap v4 pool as a single full-range position.

While full-range positions are the right default for CCAs, they are sub-optimal after the auction converts to a regular pool. As the market matures most of the full-range capital sits far from the trading price, where swaps never happen. Fees flow to active LPs that concentrate around spot, and any price gap to a subsequent CEX listing is closed by arbitrageurs at the LP's expense.

At the end of the CCA, Arrakis Pro migrates the full-range position into an actively managed Uniswap v4 vault in one atomic transaction. Teams that migrate from full-range to concentrated liquidity have historically seen \~4x lower price impact, \~3x higher fee capture, and \~4x deeper liquidity at the trading price. The team maintains custody through the vault NFT.

## What CCA delivers

CCA is built for the auction phase of a token launch. It runs a uniform-price auction in continuous time. Tokens are sold gradually, clearing prices are set by real demand, and the entire process runs onchain. At the close of the auction, proceeds and reserve tokens seed a Uniswap v4 pool at the final clearing price, and a position NFT is minted to the designated recipient. Liquidity is live immediately. For the full CCA mechanism, see [**Uniswap's CCA documentation**](https://docs.uniswap.org/contracts/liquidity-launchpad/Overview).

After CCA closes, the issuer holds a Uniswap v4 position NFT representing the seeded liquidity as a full-range position, with liquidity distributed across the entire price curve from zero to infinity. This is the appropriate default during price discovery, when the trading range is unknown and extreme moves are possible. Once price discovery completes and trading patterns emerge, the same structure becomes a major constraint: only a small fraction of capital sits near the active trading price where swaps occur.

## Why post-CCA management matters

Three dynamics emerge once trading goes live. Each is fixed by migrating the CCA position to active Arrakis management.

<Columns>
  <Card title="Full-range liquidity creates large price impacts.">
    When capital is spread from zero to infinity, only a thin slice sits at the active trading price. Historically, a \$6M full-range position has produced around 0.67% price impact on a \$10K trade. With Arrakis, the same \$6M is concentrated around spot, reducing impact to roughly 0.16%, a **76% reduction**. Live Arrakis deployments have historically seen 4x lower price impact on equivalent trades than full-range positions of equal capital.
  </Card>

  <Card title="External LPs capture the fees on your pool.">
    Once a token reaches scale, sophisticated external LPs deploy their own concentrated positions at the trading price. Their tight positions earn most of the trading fees while the issuer's full-range position keeps providing depth for free. Left unmanaged, the issuer subsidizes the market and receives mostly arbitrage flow in return. With Arrakis, dynamic fees and managed concentration keep up to 95% of trading fees with the vault instead of leaking to external LPs.
  </Card>

  <Card title="CEX listings drain value through arbitrage.">
    When a CEX lists the token at a price different from the Uniswap pool's clearing price, bots and traders arb the pool until prices match, leaking value from LPs and users. With [**Price Convergence**](/price-convergence), the Arrakis pool price updates to the CEX price automatically at trading start, removing the arbitrage opportunity entirely.
  </Card>
</Columns>

## Migration flow

Migration runs as a single `migratePositions()` call on the Arrakis migration helper contract. The full sequence is atomic: trading does not pause and the position is not exposed to MEV through a withdraw-and-redeposit window.

```mermaid actions={false} theme={null}
sequenceDiagram
    actor Issuer
    participant Helper as Migration Helper
    participant UniV4 as Uniswap v4 Pool
    participant Vault as Arrakis Vault

    Issuer->>Helper: migratePositions(positionNFT, vaultConfig)
    Helper->>UniV4: Withdraw CCA full-range position
    Helper->>Vault: Deploy and configure
    Vault->>UniV4: Deposit as concentrated position
    Helper->>Issuer: Transfer vault NFT
    Note over Issuer,Vault: All steps execute atomically in one transaction
```

<Steps>
  <Step title="Pre-migration">
    The team holds the Uniswap v4 position NFT minted at CCA close. The team and Arrakis confirm strategy parameters: tick range, fee tier, dynamic fee configuration, optional hooks such as [**Price Convergence**](/price-convergence).
  </Step>

  <Step title="Call">
    The team (or the migration helper, depending on integration) calls `migratePositions(positionNFT, vaultConfig)` on the helper contract.
  </Step>

  <Step title="Atomic execution">
    The helper consumes the Uniswap NFT, deploys and configures the Arrakis vault, deposits the underlying tokens into the vault, redeploys liquidity to Uniswap v4 at the new concentrated tick range, and transfers the vault NFT to the issuer.
  </Step>

  <Step title="Post-migration">
    The team holds the Arrakis vault NFT. Active management begins immediately. Liquidity remains on Uniswap v4.
  </Step>
</Steps>

## Arrakis benefits

After migration, the position is actively managed by one of Arrakis Pro's strategies. By default this is the [**Flagship Strategy**](/flagship), which keeps the position concentrated around spot to maximize fee capture and widens the range as volatility rises to limit impermanent loss.

As needed, other strategies fit specific launch profiles: [**Bootstrap**](/bootstrap) for inventory still skewed toward the project token, the [**Yield-Bearing Asset Strategy**](/yield-bearing-asset) for tokens that accrue value through yield, and [**Treasury Diversification**](/treasury-diversification) for gradual conversion of the project token into a quote asset.

|                              | Full-range CCA position         | Arrakis vault (post-migration)               |
| ---------------------------- | ------------------------------- | -------------------------------------------- |
| **Capital at trading price** | Small fraction                  | Majority                                     |
| **Rebalancing**              | None                            | Continuous, automated                        |
| **Fee tier**                 | Static                          | Static or volatility-adaptive (dynamic fees) |
| **v4 hooks**                 | None                            | Optional (Price Convergence)                 |
| **Operations**               | Self-managed                    | Managed by Arrakis                           |
| **Custody**                  | Self-custodial (Uniswap v4 NFT) | Self-custodial (Arrakis vault NFT)           |
| **Withdrawal**               | At will                         | At will                                      |

## Engaging before the auction

Engaging Arrakis before the auction unlocks two benefits unavailable to teams that migrate after the fact: capital planning that accounts for concentrated depth, and Price Convergence at listing.

<Card title="Capital planning">
  A team raising \$10M can model the auction with Arrakis's concentrated depth in mind from the start. Where a full-range CCA position would require around \$4M to deliver adequate trading depth, the same depth through Arrakis requires roughly \$1M. The remaining \$3M is freed for operations, development, or treasury. Alternatively, the full \$4M through Arrakis produces depth equivalent to \$16M or more in full-range positions.
</Card>

<Card title="Price Convergence at listing">
  Configured before the auction, [**Price Convergence**](/price-convergence) updates the Uniswap pool price to match the CEX listing price the moment trading opens, preventing the listing-window arbitrage described above. Setup requires sharing the CEX listing target with Arrakis ahead of time.
</Card>

## Supported deployments

The Arrakis migration helper is deployed on chains where Uniswap v4 is live and Arrakis Pro vaults are supported.

<Card title="Integrate Arrakis" icon="laptop" href="https://qxqhpatmzz7.typeform.com/to/IZdNgmmM?typeform-source=docs.arrakis.finance">
  Talk to the Arrakis team about your CCA launch.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="How does this compare to running our own concentrated position?">
    In practice, teams rarely run their own concentrated position post-CCA. The operational burden keeps most teams from doing it themselves: continuous monitoring, tick-range decisions, gas on every rebalance, MEV exposure during rebalances, and timing risk on each adjustment. The realistic alternatives are to deploy full-range and accept fee leakage to active LPs, or to migrate to Arrakis. Arrakis runs the management automatically through its strategy infrastructure, with the team retaining self-custody through the vault NFT.
  </Accordion>

  <Accordion title="Can we change strategy parameters after migration?">
    Yes. Tick range, fee structure, hook configuration, and the active strategy are all reconfigurable. Reconfiguration runs as an authenticated call from the vault NFT holder.
  </Accordion>
</AccordionGroup>


# Yield-Bearing Asset
Source: https://docs.arrakis.finance/yield-bearing-asset



Arrakis Pro's Yield-Bearing Asset Strategy allows issuers of yield-accruing tokens, for example syrupUSDC or USD.ai, to maintain consistent sell-side liquidity as the asset's price drifts upward with yield, avoiding the standard problem where passive LP positions fall out of range as yield accrues.

The strategy is designed for tokens whose value rises predictably over time, such as yield-bearing stablecoins, liquid staking tokens, and tokenized treasury or private credit products.

The vault holds inventory heavily skewed toward the quote asset (up to 99%, depending on expected sell-side demand). Rebalances trigger automatically as the asset's exchange rate drifts.

## How it works

The team configures:

1. The asset pair (yield-bearing token paired with a quote asset such as ETH or a stablecoin).
2. The inventory skew (heavily weighted toward the quote asset, up to 99%, depending on expected sell-side demand).
3. The ERC-4626 vault the yield-bearing token mints and redeems against, used to rebalance the Arrakis vault's inventory as it accumulates one side of the asset.

The strategy deploys the inventory as concentrated liquidity around the spot price, using narrow tick spacing for tight spreads. Most of the quote asset sits at and slightly above the current price, ready to fill sell flow from the yield-bearing asset back to the quote. On Uniswap v4, the pool can run dynamic fees through the Arrakis v4 hook, adjusting to the pair's volatility.

As yield accrues to the underlying, the yield-bearing token appreciates against the quote asset, and the pool price drifts upward in tandem. The vault monitors the ERC-4626 vault's reported exchange rate and triggers a rebalance once the position has drifted past a configured tick threshold. A cooldown between rebalances and a minimum-size threshold keep the strategy from churning on small moves or noise.

On rebalance, the vault works through three steps, all in a single atomic transaction:

<Steps>
  <Step title="Withdraw">
    The vault withdraws the full position.
  </Step>

  <Step title="Mint or redeem">
    It calls the ERC-4626 vault to mint or redeem, matching the new inventory target.
  </Step>

  <Step title="Redeploy">
    It redeploys liquidity around the updated spot price, preserving the configured skew.
  </Step>
</Steps>

<Note>
  **Exchange-rate deviation check.** If the pool price diverges from the ERC-4626 vault's reported NAV beyond a configured threshold (a signal of depeg, oracle drift, or manipulation), the rebalance is blocked.
</Note>

Buy-side liquidity in the pool can be configured to be intentionally thin if buyers typically obtain the yield-bearing asset by minting through the ERC-4626 vault directly. The strategy then optimizes for the redemption side the vault does not serve efficiently: converting the yield-bearing asset back into the quote on demand. The team can freely configure how much of the deposited liquidity is dedicated to the buy versus sell side, depending on the token's minting and redemption procedures.

The team can pause, reconfigure, or withdraw at any time.

## Considerations

<Card title="The strategy assumes value drifts predictably upward.">
  Built for assets that accrue value over time through yield. Assets whose exchange rate is volatile rather than monotonically increasing, or whose value drifts downward, require a different strategy.
</Card>

<Card title="Sell-side depth, buy-side thin by design.">
  The strategy concentrates liquidity on the sell side. Pool trades that buy the yield-bearing asset will see thinner liquidity and wider effective spreads than trades that sell it. The expectation is that buyers route through the ERC-4626 vault directly.
</Card>

<Card title="Dependency on the ERC-4626 vault.">
  Rebalances depend on the yield-bearing asset's native vault for mint and redeem. If the vault pauses redemptions, the strategy cannot rebalance through the direct path until the vault resumes.
</Card>

<Card title="Requires atomic mint/redeem on the deployment chain.">
  The strategy depends on calling the ERC-4626 vault's mint and redeem functions within the same transaction as the rebalance. Chains or deployments where the underlying vault does not support that pattern rely on other mechanisms to rebalance the inventory. Talk to the Arrakis team to find a solution that suits the token's requirements.
</Card>

<Card title="Depeg events pause rebalancing.">
  If the pool price diverges far enough from the vault's reported exchange rate, rebalancing is paused to protect against manipulation. Liquidity may sit out of range during the event until the gap closes.
</Card>

## FAQ

<AccordionGroup>
  <Accordion title="What kinds of assets work with this strategy?">
    The strategy is built for tokens whose value accrues over time through yield, exposed through an ERC-4626 or equivalent smart-contract vault architecture. This includes yield-bearing stablecoins backed by interest-bearing reserves, liquid staking tokens that accrue staking rewards via exchange-rate increases, and tokenized treasury or credit products where yield compounds into the token's redemption value. Tokens that rebase to track yield (rather than appreciating via exchange rate) follow a different mechanism and have to be wrapped to work with this strategy.
  </Accordion>

  <Accordion title="How is this different from running a passive LP position on a yield-bearing pair?">
    A static concentrated liquidity position falls out of range as the yield-bearing token appreciates against its quote asset. The LP must either widen the range, losing capital efficiency, or rebalance manually, subject to gas costs, timing risk, and operational overhead. The Yield-Bearing Asset Strategy automates the rebalance through the ERC-4626 vault, keeping liquidity at the current price continuously and converting inventory through mint and redeem rather than market swaps.
  </Accordion>

  <Accordion title="What happens during a depeg or sharp move in the underlying?">
    The vault monitors the pool price against the ERC-4626 vault's reported exchange rate. If divergence crosses the configured threshold, rebalancing pauses and the position holds its current state. This prevents the strategy from rebalancing through a manipulated or stressed pool. The position may sit out of range during the event. Rebalancing resumes once the divergence closes or the team intervenes.
  </Accordion>

  <Accordion title="Can the strategy be combined with existing yield-bearing liquidity?">
    Yes. Teams typically migrate existing manual yield-bearing LP positions into an Arrakis vault. The vault consolidates the team's inventory under one strategy and removes the manual rebalancing the team would otherwise run.
  </Accordion>
</AccordionGroup>


# Yield-Bearing Assets
Source: https://docs.arrakis.finance/yield-bearing-assets-rwas

Keep sell-side liquidity in range for yield-accruing assets as their price drifts, so the asset stays convertible at scale and usable as collateral.

A yield-bearing asset (e.g. syrupUSDC, USDAI, etc) is only as useful as its available liquidity. Holders use these tokens as collateral in lending loops, perps, and structured positions, and every one of those use cases depends on converting the asset back to its quote on demand. That requires deep, reliable sell-side liquidity onchain. The problem is that yield accrual works against passive liquidity: as the token appreciates with its yield, a static concentrated position drifts out of range, sell-side depth thins exactly when holders need it, and the asset becomes harder to use as collateral.

Arrakis Pro keeps sell-side liquidity in range as the asset's price drifts. The [**Yield-Bearing Asset Strategy**](/yield-bearing-asset) tracks the asset's exchange rate through its ERC-4626 vault and repositions automatically, holding deep sell-side depth along the yield curve without manual intervention. The team keeps self-custody through the vault NFT.

## Why yield-bearing assets need active liquidity

Two problems are specific to assets that accrue value over time. Each is addressed by active management tuned to the yield curve.

<Card title="Yield accrual pushes passive liquidity out of range.">
  A yield-bearing token appreciates against its quote asset as yield accrues, so the pool price drifts steadily upward and a static concentrated position falls out of range. The LP either widens the range and loses capital efficiency, or rebalances by hand, repeatedly. The Yield-Bearing Asset Strategy reads the asset's exchange rate from its ERC-4626 vault and repositions automatically as the rate drifts.
</Card>

<Card title="Collateral utility depends on reliable exit liquidity.">
  For a yield-bearing asset to function as DeFi collateral, holders have to convert it back to the quote on demand: to repay debt, unwind a loop, or exit during stress. Lending markets list assets on the strength of that exit liquidity, and thin or out-of-range depth limits how far the asset can scale. Inventory is skewed heavily toward the quote asset to prioritize sell-side depth, so the asset stays convertible at scale.
</Card>

## Which assets this fits

The strategy fits any token whose value accrues through yield and is exposed through an ERC-4626 vault. The common categories:

| Asset class               | Typical yield source                      | Liquidity need                                                                      |
| ------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------- |
| Yield-bearing stablecoins | Interest-bearing reserves, private credit | Deep sell-side depth so the asset converts to its quote with low slippage on demand |
| Liquid staking tokens     | Staking rewards via exchange-rate growth  | In-range depth that tracks the upward drift                                         |
| Tokenized treasuries      | Short-term government debt                | Reliable exit liquidity for an RWA-backed instrument                                |
| Tokenized private credit  | Institutional loan interest               | Sell-side depth for a less liquid underlying                                        |
| Yield tokenization        | Split principal and yield tokens          | Concentrated depth for two thin order books per asset                               |

Tokens that track yield by rebasing (changing balance rather than exchange rate) follow a different mechanism and are not the primary fit.

## How Arrakis fits a yield-bearing asset issuer

The yield-bearing asset itself runs on the [**Yield-Bearing Asset Strategy**](/yield-bearing-asset). Issuers often have a second token to manage as well: a governance or utility token that launches and trades like any other project token. That token uses the standard lifecycle.

```mermaid theme={null}
flowchart LR
    subgraph YB[Yield-bearing asset]
      direction TB
      S1[Yield-Bearing Asset Strategy<br/>Sell-side depth tracks the yield curve]
    end
    subgraph GOV[Governance / utility token]
      direction TB
      S3[Bootstrap then Flagship<br/>Launch and ongoing management]
    end
    Issuer([Yield-bearing<br/>asset issuer]) --> YB
    Issuer --> GOV
```

For the governance token, [**Bootstrap**](/bootstrap) handles the launch and [**Flagship**](/flagship) handles ongoing management. Both tokens sit in self-custodial Arrakis vaults under the issuer's control.

## Supported infrastructure

| Layer           | Supported                                                                                                                                                       |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Chains          | Ethereum, Base, Arbitrum, Optimism, BNB Chain, Unichain, Ink, Hyperliquid, Solana                                                                               |
| DEXs            | Uniswap v3 and v4, Aerodrome Slipstream, Velodrome Slipstream, PancakeSwap v3 and v4 (Infinity), Hyperliquid, Hadron PropAMM serving Jupiter and Titan (Solana) |
| Asset interface | ERC-4626 vault for the yield-bearing token (required for the strategy's mint and redeem path)                                                                   |

## Integration path

Onboarding requires confirming the ERC-4626 vault interface and configuring the inventory skew for the asset's expected sell-side demand.

<Steps>
  <Step title="Discovery">
    Conversation with the Arrakis team about the asset, its yield mechanism, the ERC-4626 vault, and the target sell-side depth. Arrakis can analyze the asset's current onchain liquidity and simulate the improvement.
  </Step>

  <Step title="Configuration">
    Vault parameters confirmed: pair, inventory skew (up to 99% quote), the ERC-4626 vault used for mint and redeem, exchange-rate deviation guardrails.
  </Step>

  <Step title="Deployment">
    Arrakis deploys the vault on the chosen DEX and chain. The vault NFT transfers to the issuer's multisig.
  </Step>

  <Step title="Active management begins">
    The strategy tracks the exchange rate and repositions automatically. The team can pause, reconfigure, or withdraw at any time.
  </Step>
</Steps>

## FAQ

<AccordionGroup>
  <Accordion title="Our asset earns yield by rebasing, not by an exchange rate. Does this work?">
    The Yield-Bearing Asset Strategy is built around an ERC-4626 exchange rate that drifts upward as yield accrues. Tokens that rebase (where balances change rather than the exchange rate) follow a different mechanism and must be wrapped before they can use the Yield-Bearing Asset Strategy. The Arrakis team can advise on the right setup during discovery.
  </Accordion>

  <Accordion title="Why does it make sense to skew inventory heavily toward the quote asset?">
    Yield-bearing assets are often used as collateral, so the liquidity that matters is sell-side: holders converting the asset back to its quote on demand. Buyers can usually mint the asset directly from its ERC-4626 vault, so the pool does not need deep buy-side inventory. Skewing the inventory toward the quote (up to 99%) puts capital where it is actually used. The [**Yield-Bearing Asset Strategy**](/yield-bearing-asset) page covers this in full.
  </Accordion>

  <Accordion title="Do we have to provide all the quote-side capital ourselves?">
    The issuer provides the quote reserves that back sell-side depth, sized to the target depth for the asset. The inventory skew concentrates capital on the sell side, so more of every dollar contributes to the exit depth that matters. Sizing is set during discovery against the asset's expected exit volume.
  </Accordion>

  <Accordion title="What happens to sell-side depth during a depeg or stress event?">
    The strategy stops repositioning when the pool price diverges far from the vault's exchange rate, so it does not rebalance through a manipulated or stressed price. The position can sit out of range until the gap closes. The [**Yield-Bearing Asset Strategy**](/yield-bearing-asset) page covers the guardrail behavior.
  </Accordion>
</AccordionGroup>