RFQ and Onchain Liquidity

OnRe's RFQ system provides program-native liquidity for ONyc, allowing supported pairs to be bought or sold directly against liquidity managed by the OnRe program.

Quotes are generated from current on-chain state and executed atomically with a caller-defined minimum output. Availability depends on the relevant pair being configured, enabled, and sufficiently funded.

Two Liquidity Paths

Onyc supports two distinct liquidity paths:

	RFQ / Prop AMM	Primary Redemption
Use Case	Immediate onchain buy or sell	Redemption directly through OnRe
Execution	Atomic	Asynchronous
Availability	Requires an active and sufficiently funded pair	Subject to redemption eligibility and protocol fulfillment
Settlement	Completed within the transaction	May be partially fulfilled

Primary redemption requests are not immediate swaps. Creating a request locks the corresponding ONyc and creates an on-chain claim pending fulfillment.

How the RFQ Works

The RFQ uses OnRe's existing pricing, redemption, and market state. Buy-side pricing comes from the canonical Offer, while the corresponding RedemptionOffer supplies sell-side fees and the target balance for the redemption vault. PropAmmPairState controls whether a pair is active and tracks buy and sell pressure, while MarketStats.tvl provides the TVL input used to calculate the liquidity target.

Sell-side payouts are funded by the redemption vault. Fees and excess buy-side proceeds are routed to separate vaults to keep RFQ activity distinct from regular offers and primary redemptions.

Instructions

Operation	Quote	Execute
Buy ONyc	quote_swap_buy	open_swap_buy(token_in_amount, minimum_out)
Sell ONyc	quote_swap_sell	open_swap_sell(token_in_amount, minimum_out)

Quotes and execution are guarded by the global kill switch. Execution also requires the relevant pair and offer state to be enabled.

The quote is not a liquidity reservation. State can change between quote and execution, so the caller must set minimum_out and should simulate the final transaction.

Buying ONyc

An RFQ buy exchanges a supported asset for ONyc at the current offer price. The permissionless fee is deducted from the input amount before calculating ONyc output.

Net inflows are first used to refill the redemption vault when its balance is below the configured liquidity target. Any remaining proceeds are routed to the Prop AMM proceeds vault.

fee = ceil(token_in_amount × permissionless_fee_bps / 10,000)
net_input = token_in_amount - fee

Buy inflows refill the redemption vault only up to the configured liquidity target.

target = TVL × vault_target_bps / 10,000
headroom = max(0, target - current_redemption_vault_balance)
refill = min(net_input, headroom)
proceeds = net_input - refill

The implementation converts the TVL-scale target into the input asset's decimals before comparing it with the vault balance.

Selling ONyc

An RFQ sell exchanges ONyc for a supported asset using liquidity held in the redemption vault.

The program first applies the route-specific sell fee, then converts the remaining ONyc at the current offer price. Final output is adjusted based on available liquidity, recent sell pressure, trade size, and cadence before the caller's minimum_out is enforced.

The redemption vault balance is the hard liquidity constraint. Configuration can make pricing more conservative, but cannot make more liquidity available than the vault actually holds.

Dynamic Sell Pricing

Sell pricing adjusts as available liquidity is consumed. Larger trades use more of the available liquidity and may therefore receive a larger haircut. Recent net selling and repeated sells within the configured cadence window can also increase the haircut, while buy flow can offset current-epoch sell pressure.

effective_liquidity = min(
  pressure_adjusted_wall,
  actual_vault_balance,
  TVL_target_when_configured
)

utilization = raw_sell_value / effective_liquidity
output = raw_sell_value × (1 - haircut(utilization, pressure, cadence))

Integrators should use the quote instruction rather than reimplementing the curve.

Liquidity Target

Each redemption market can define a vault_target_bps, which sets the target redemption-vault balance as a percentage of TVL.

When the target is active, RFQ buy flow refills the redemption vault up to that level before excess proceeds are routed elsewhere. Setting vault_target_bps to 0 disables target-based refill, in which case sell pricing relies on actual vault liquidity.

The target is a liquidity-management parameter, not a guaranteed level of redemption capacity.

Accounting Separation

RFQ activity is separated across dedicated fee, proceeds, and redemption vaults rather than being routed through a single account.

Bucket	Purpose
prop_amm_buy_fee	RFQ buy fees
prop_amm_sell_fee	RFQ sell fees
prop_amm_proceeds	Net RFQ buy inflow not used for redemption-vault refill
redemption_fee	Primary redemption fulfillment fees
offer_fee	Regular take_offer_v2 fees
permissionless_offer_fee	take_offer_permissionless_v2 fees
offer_proceeds	Net v2 offer inflow not routed to redemption liquidity

This keeps fees, RFQ proceeds, and primary redemption flows independently traceable. Integrators should reference the fee field associated with the specific route being used.

Availability and Failure States

Before exposing an RFQ route, verify that the market is currently available:

1. Fetch State and check the global kill switch.

2. Fetch the canonical Offer and check disabled and allow_permissionless where relevant.

3. Fetch the reverse-direction RedemptionOffer and check its disabled flag.

4. Fetch PropAmmPairState and verify that the pair is enabled.

5. Read or quote against current redemption-vault liquidity.

6. Check MarketStats freshness when the pair uses a TVL-based target.

If these conditions are not met, the route should be treated as temporarily unavailable rather than retried indefinitely.

Router Integration

For execution, routers should preserve the quoted direction and mint ordering, apply minimum_out according to their slippage policy, and simulate the final account list before submission. Quotes reflect current state and should not be treated as liquidity reservations. Original OnRe program errors should be retained for monitoring and debugging.

Secondary-Market Routing

The OnRe RFQ is an additional source of ONyc pricing and liquidity; it does not replace external liquidity venues. Routers such as Titan can compare an RFQ quote with available secondary-market routes and select the best execution path.

External pools price ONyc through market activity, while the OnRe RFQ uses program pricing and controlled redemption liquidity. The best route can therefore vary based on trade direction, size, redemption-vault liquidity, and broader secondary-market conditions.