Aperturefinance
Aperturefinance Pool Triggers and Execution Limits
Aperturefinance automates rebalancing when a selected liquidity position meets its configured pool-price, token-ratio or time-based condition. A triggered action must also satisfy applicable duration, slippage and gas limits. Those settings explain why a reached threshold may leave liquidity unchanged and how execution differs from trigger configuration.
Updated on
Key takeaway: Editing a TWAP-based trigger restarts its waiting period, so repeated updates can postpone eligibility for a pending rebalance.
Pool Price and Position Composition
Pool-price triggers evaluate one token in the other token’s units, using the selected pool’s on-chain pricing. A quote in a pool token differs from a universal USD feed. USD-price triggers are no longer supported. For volatile-token pairs, the immediate trigger input is the current liquidity-pool price. A market chart from another venue is a separate price observation. The quote that it displays does not replace the rule’s pool-derived input.
Position-ratio triggers assess the token composition of the selected liquidity position and also use current pool pricing. Price and ratio rules express different conditions: one concerns the exchange quote, while the other concerns the position’s composition. A position ratio does not describe the token distribution across the entire wallet.
Why Can a Configured Trigger Remain Unexecuted?
A configured trigger can remain unexecuted because its waiting period is incomplete or its gas and slippage settings restrict execution. Duration-based price and ratio settings use a time-weighted average price, or TWAP.
| Trigger Option | Condition Input | Execution Limit or Outcome |
|---|---|---|
| Pool Price | Current on-chain pool price for a volatile-token pair. | Gas and slippage limits can prevent the rebalance. |
| Pool Price With TWAP | Arithmetic TWAP from the pool’s on-chain oracle. | Uses available history and waits at least the selected duration. |
| Position Token Ratio | Token composition of the position, using current pool pricing. | The ratio threshold does not override transaction limits. |
| Ratio With Duration | Ratio-based condition with the corresponding TWAP pricing input. | The duration adds a waiting requirement before execution. |
| Scheduled Time | Time-based condition for automated rebalancing or closure. | Rebalancing creates a replacement position; closure returns assets to the wallet. |
| Shared Constraint | The selected condition determines when an action becomes due. | A due rebalance still has to satisfy its execution settings. |
Consider a duration-based trigger that remains within its required waiting period, with its liquidity position otherwise unchanged. Leaving the settings unchanged preserves the existing wait. Editing the trigger restarts that period, even if the new threshold resembles the old one. The edit changes the pending instruction before rebalancing; it does not itself establish that liquidity has moved.
After the required wait, tight transaction limits can still explain missing execution. Increasing slippage tolerance accepts more price movement; increasing the gas ceiling accepts greater gas expense. These changes relax a protection before a later execution attempt. Actual liquidity removal and addition to the replacement position establish the completed rebalance.
Thresholds and Rebalance Targets
Rebalance targets determine the replacement position’s range and composition, while trigger thresholds specify the condition that initiates the adjustment. The range can use a percentage around the future pool price, an interval in token terms or a target ratio with a chosen tick-spacing width. Tick spacing belongs to range configuration; it is separate from a waiting duration. The setup reference price therefore need not become the center of the replacement range.
Percentage-based trigger setup expresses movement relative to a reference price. Absolute-token settings express the condition in one pool token’s units. When the target range centers on the future pool or spot price, its location follows that later quote.
TWAP Duration and Available Oracle History
TWAP-based rules average on-chain pool data, while the configured duration establishes a minimum waiting period before the trigger can fire. The calculation uses an arithmetic TWAP from the on-chain price oracle.
Oracle history can be shorter than the requested averaging window. In that case, the calculation uses the available data.
Pools with low trading volume tend to have fewer oracle observation slots and shorter histories available for TWAP calculations.
A trigger waits at least the specified duration even when its usable oracle history is shorter than the requested window. Likewise, a reached spot-price threshold does not show that the corresponding TWAP-based condition has been met.
Slippage Boundaries From Submission to Execution
Slippage limits constrain pool-price movement between transaction submission and the start of execution, with minimum token outputs governing acceptance. The rebalance calculates those minimum outputs from the selected slippage setting. If actual token outputs fail the thresholds, the transaction reverts.
Trigger evaluation and slippage checks concern different moments. The trigger determines whether the configured action is due. Slippage compares the submission-time pool price with the price at execution start. Movement between those moments can affect an adjustment after its trigger condition has been detected.
A wider tolerance changes the output protection that the transaction applies. It does not improve the pool price or eliminate price movement.
Aperturefinance can incur gas costs when an on-chain transaction fails. Its Liquidity Intent charges include a network-specific gas surcharge to account for failures caused by slippage or other execution problems.
Gas Ceilings and Separate Charges
Gas ceilings limit rebalance gas expense relative to the dollar value of the position being managed. Under the documented Recurring Rebalance configuration, the maximum gas fee ceiling is 20% of the managed position’s dollar value. A lower selected ceiling can prevent rebalancing during expensive network conditions even when the threshold has been reached. The permitted ceiling expresses a cost tolerance; it does not predict the gas that every rebalance will spend.
The rebalance service fee uses two components: 0.15% of position value and a $0.15 flat charge per rebalance. These service charges are separate from the gas expense that a configured ceiling permits.
The gasless payment model shifts upfront gas payment to solvers and deducts fees in the user’s chosen tokens. Gas still has an economic cost, and a gas ceiling continues to matter when the underlying action is a rebalance.
Liquidity Movement and Replacement Positions
A rebalance normally removes liquidity, collects its fees, swaps tokens and adds liquidity to a replacement position. The new range and token split reflect the selected target. Unclaimed trading fees join the new position after rebalancing. The interface presents this adjustment as one rebalance operation.
Concurrent Triggers and Position IDs
Concurrent one-time triggers compete on the same position, and the first condition met determines which configured action takes precedence. The documented allowance is three rebalance triggers and three close triggers open together on a position. After rebalancing creates a new position ID, the remaining triggers attached to the old position are invalidated. Their old-position instructions do not transfer to the replacement. This consequence differs from a trigger that is still waiting under restrictive transaction settings.
A recurring strategy keeps rebalancing when its trigger condition is met again. Several one-time triggers remain competing rules on one position; they do not create repeated execution by themselves.
Mode Compatibility Before Trigger Configuration
Recurring Rebalance is not supported on Manta Pacific, even though ApertureSwap provides pool access on that network. Strategy setup selects a chain and DEX before configuring a rule, so pool access and mode support both matter at that stage. This unsupported-mode setup can return status code 400. Editing slippage or a gas ceiling addresses transaction limits; it cannot add recurring-strategy support to Manta Pacific.
Helpful answers about Aperturefinance
Can a Strategy Assign Different Rebalance Actions Above and Below Its Trigger Range?
A recurring strategy supports different rebalance actions for its upper and lower trigger conditions. This dual-action configuration applies to price-based rules and works similarly for ratio-based rules. A satisfied condition invokes its configured action, subject to the strategy’s execution settings.
Where Are a position’s Active Triggers Displayed?
Active triggers appear on the liquidity position’s detail page. The list identifies the rules attached to that position, which is useful when several rebalance or close conditions are open. A displayed trigger represents a configured instruction; its presence alone does not establish that its action has executed.
Does Each Liquidity Position Receive Its Own 50-Trigger Allowance?
The 50-trigger setup limit applies to an address across its positions, so each position does not receive a separate 50-trigger allowance. Requests for more than 50 triggers require direct contact with Aperturefinance.
Could Pool Initialization Prevent a New Strategy Position From Being Created?
Some pools require initialization before liquidity can be added, which affects creation of the position that a new strategy needs. The new-position setup creates liquidity before configuring its recurring rule. This prerequisite concerns position creation and is separate from a configured trigger waiting for its condition.
Who Can Increase a Pool oracle’s Observation Capacity?
Anyone can pay gas to increase the number of observation slots in the on-chain price oracle. More slots provide capacity for additional price history; increasing capacity does not immediately create past observations. A TWAP calculation still uses the history that is actually available for the selected pool.
Is an Existing Liquidity Position Eligible for Recurring Strategy Setup?
An existing active liquidity position can be selected for recurring strategy setup where that mode is supported. This entry path avoids creating a new position solely to configure a rule. The selected chain and DEX must support the recurring mode.