Skynet V3 Market-Making Support

Title: Skynet V3 Market-Making Support

Author(s): SaucerSwap Labs

SaucerSwap Voting Interface: TBA

Related Discussions: N/A

Submission Date: June 3, 2026


Summary

This proposal introduces a market-making support structure for SaucerSwap V3 launch liquidity.

SaucerSwap V3 introduces central limit order book markets. Unlike V1 and V2 AMMs, V3 launch quality depends on active two-sided liquidity, reliable reference pricing, and sufficient depth near fair value. Dedicated market-making support can help make the initial V3 markets usable while organic liquidity and external integrations develop.

The working direction is to evaluate a collateralized financing structure under which SAUCE may be posted as collateral instead of sold upfront to acquire all required inventory. Final market coverage, inventory requirements, collateral terms, costs, custody, and risk controls remain subject to confirmation during RFC review before any binding vote.

Abstract

This proposal asks the DAO to review a Skynet market-making support arrangement for SaucerSwap V3 launch.

The objective is to support initial V3 market quality while minimizing unnecessary treasury disruption. The preferred working structure is collateralized rather than treasury-sale-based, but final terms must be disclosed before the proposal advances to a formal vote.

Current state and what changes

The V3 Launch Economics proposal establishes the initial V3 market and fee framework. It addresses market selection, maker/taker fees, maker rebates, xSAUCE fee discounts, and V3 fee routing.

This RFC addresses a separate launch operations question: how the DAO should support early order-book liquidity.

Current state:

  • V3 launch markets require active liquidity support to be usable from day one.
  • The DAO treasury is primarily SAUCE-denominated.
  • Acquiring all required market-making inventory through upfront treasury conversion may create unnecessary execution pressure.

Proposed change:

  • Evaluate a Skynet market-making arrangement for V3 launch support.
  • Prioritize a collateralized structure where SAUCE may be posted as collateral rather than immediately sold for all required inventory.
  • Finalize market coverage, collateral, cost, custody, and risk terms during RFC review before any binding vote.

Motivation

Order-book markets are most useful when users can see and execute against reliable two-sided liquidity. Thin or discontinuous books can make a technically live market feel unusable and can weaken early confidence from users, integrators, and external market makers.

A market-making support arrangement can help:

  • maintain visible bids and asks;
  • improve early user experience;
  • support reference-price alignment;
  • provide more reliable launch conditions for traders and integrators;
  • reduce the risk that initial V3 metrics are distorted by thin liquidity.

At the same time, the DAO should avoid unnecessary pre-launch treasury disruption. A collateralized structure may preserve flexibility by allowing the DAO to support market-making inventory without selling a large amount of SAUCE in a short period.

Specification & Rationale

1. Market-making support provider

The DAO should evaluate a Skynet market-making support arrangement for V3 launch liquidity. Final authorization, if any, should be based on disclosed terms before the proposal advances to a formal vote.

2. Initial market scope

The launch market scope under discussion is the initial V3 market set:

  • HBAR-USDC
  • WETH-USDC
  • WBTC-USDC
  • SAUCE-USDC
  • USDT0-USDC

Final market support remains subject to Skynet confirmation and DAO review.

3. Expected structure

The preferred working direction is a collateralized financing structure. Under this model, SAUCE may be posted as collateral to support market-making inventory or financing rather than requiring the DAO to sell a large amount of SAUCE upfront.

The final structure may be collateralized, inventory-provided, or hybrid. The selected structure should be disclosed before any formal vote.

4. Terms to finalize before vote

The formal proposal should specify:

  • supported markets;
  • inventory requirements by market;
  • required SAUCE collateral amount;
  • collateral treatment, haircut, and return obligations;
  • retainer, risk premium, financing cost, or other economics;
  • custody and control of collateral and inventory;
  • risk controls and pause conditions;
  • treatment of market-making PnL, losses, rebates, and fees;

Rationale

A direct inventory-provision model may require the DAO to acquire or convert assets for each market. Because the treasury is primarily SAUCE-denominated, that could require selling a material amount of SAUCE in a short period.

A collateralized structure may support the same launch objective while reducing immediate market impact from treasury conversions. This preserves treasury flexibility and gives the DAO a clearer path to evaluate costs, collateral risk, and operational controls before execution.

Risks / Considerations

Counterparty and collateral risk

If SAUCE is posted as collateral, the DAO may take counterparty, custody, and collateral-treatment risk. Final terms should define custody, permitted use, default treatment, return obligations, termination rights, and any collateral haircut or risk premium.

Market-making risk

Market making can lose money due to volatility, adverse selection, stale pricing, inventory imbalance, or technical failure. Final terms should define supported markets, inventory limits, pause conditions, risk controls, and loss treatment.

Economic cost

A collateralized or inventory-provided structure may include a retainer, risk premium, financing cost, or other economics. These costs should be disclosed before the proposal advances to a formal vote.

Timing risk

V3 launch readiness is time-sensitive. Opening the RFC now allows the DAO to review the structure while final terms are clarified. Binding authorization should wait until those terms are disclosed.

Open Items During RFC

  • Whether Skynet will support all five initial V3 markets at launch.
  • Required inventory by market.
  • Whether the final structure is collateralized, inventory-provided, or hybrid.
  • Required SAUCE collateral amount.
  • Collateral treatment, haircut, and return obligations.
  • Any retainer, risk premium, financing cost, or other economics.
  • Custody and control of collateral and inventory.
  • Risk controls and pause conditions.
  • Treatment of market-making PnL, losses, rebates, and fees.
  • Final execution timing relative to V3 launch.

Voting Options

For: Advance with a Skynet market-making arrangement for V3 launch support, subject to final disclosed terms for market scope, collateral, economics, custody, risk controls, and implementation authority.

Against: Do not authorize the proposed Skynet market-making arrangement.

Abstain: Formal abstention.

2 Likes

Thanks for bringing this to RFC before finalizing terms Larry, that transparency is appreciated and the right approach given how much is still open.

The collateralized structure makes sense on the surface, using SAUCE as collateral rather than selling treasury assets avoids unnecessary downward pressure on the token and preserves flexibility. That part I support in principle.

That said, the open items list is long and several of them are critical before this should advance to a formal vote. A few specific questions:

On custody and collateral treatment, who holds the SAUCE during the arrangement and under what conditions can Skynet access or use it? If Skynet takes losses from market making activity, how is that reconciled against the collateral? Is there a liquidation threshold or does the DAO bear full downside?

On the five initial markets, HBAR/USDC already has meaningful organic liquidity through V2. Is market-making support actually needed there at launch or would resources be better concentrated on thinner pairs like WBTC/USDC and WETH/USDC where the gap between V3 and existing liquidity is larger?

On timing, the proposal acknowledges V3 launch is time sensitive but also says binding authorization should wait for disclosed terms. What is the realistic timeline for finalizing those terms and does that timeline actually fit within the V3 launch window?

Looking forward to seeing the full terms when they are ready.

Interesting direction overall. Supporting V3 launch liquidity makes sense because order books live or die based on depth and reliable spreads, especially during the early stages.

The collateralized SAUCE approach appears more capital efficient than forcing large treasury sales upfront, which could create unnecessary sell pressure. My biggest focus before any formal vote would be transparency around collateral treatment, custody, haircut percentages, default scenarios, and who ultimately absorbs market-making losses if volatility becomes extreme.

I also think clear pause conditions and PnL treatment should be defined early. If Skynet h supports launch liquidity, the structure should strengthen market quality without creating hidden treasury risk. Looking forward to seeing the finalized terms before authorization.

Thanks both for your feedback @zeeezu @DeFiMike.

Following additional discussion with Skynet, the structure proposed is a SaucerSwap-provided inventory model.

Under this structure, Skynet would support the initial V3 market set:

  • HBAR-USDC
  • WETH-USDC
  • WBTC-USDC
  • SAUCE-USDC
  • USDT0-USDC

The commercial terms are:

  • Flat retainer fee of $5,000/month
  • Initial term of 1 month
  • SaucerSwap provides the initial inventory
  • Skynet provides market-making operations on SaucerSwap V3
  • PnL remains with SaucerSwap through the inventory balance returned at repayment

The initial inventory requirement is 8,108,108 SAUCE equivalent. Under the proposal, SaucerSwap Labs will provide the initial market-making inventory to Skynet. If the proposal is approved, the DAO will reimburse SaucerSwap Labs in SAUCE at the applicable market value for the inventory provided. This avoids requiring the DAO to directly source each inventory asset.

The relevant performance standards are:

  • Trading software active at least 99% of exchange uptime
  • Spread below 0.5%, depending on exchange fees and SaucerSwap’s preference
  • Market depth of at least 25 order sizes on both sides, depending on exchange limits

To clarify the governance treatment: the DAO retains economic exposure to the market-making inventory, including PnL, with all proceeds going toward SAUCE buybacks subject to the V3 BrewSaucer routing. SaucerSwap Labs will serve as the operational bridge to Skynet.

This comment is a formal amendment to the RFC and supersedes any inconsistent commercial or inventory-structure language in the original post.

1 Like