Reference

Rule reference

Inspect every structured rule type supported by the current parser and manual catalog.

Documentation index

Fee

Fee rules

buyFeeBuy fee

Represents a percentage taken from buys, optionally for an early window or only above an ETH amount.

Recognized instruction examples

Take 1% on buys.

Charge 4% on buys above 1 ETH.

Take 3% on buys for the first hour.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'buyFee', percent, durationMinutes?, aboveEth? }

Required: percent
Optional: durationMinutes, aboveEth
Units: percent is percentage points of each buy; durationMinutes is minutes; aboveEth is ETH.

Valid structured example

{ type: 'buyFee', percent: 3, durationMinutes: 60 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The validator rejects percent below 0 or above 25. Duration and above-ETH thresholds have no domain-specific range check.

Bounds. The validator enforces 0%–25%. The editor prevents negative input.

Conflicts. No direct duplicate-side conflict check; exact duplicate objects are normalized away.

Rejected or incomplete examples

Take 30% on buys.Recognized, then rejected because buy fees must be between 0% and 25%.

Behavior Score and current edge

BUY source, fee percentage, and optional FIRST/ABOVE condition.

Current edge. Large-trade and temporary conditions are represented but not executed today.

Frontend model only

sellFeeSell fee

Represents a percentage taken from sells, optionally for an early window or only above an ETH amount.

Recognized instruction examples

Take 2% on sells.

Charge 4% on sells above 1 ETH.

Take 5% on sells for the first 24 hours.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'sellFee', percent, durationMinutes?, aboveEth? }

Required: percent
Optional: durationMinutes, aboveEth
Units: percent is percentage points of each sell; durationMinutes is minutes; aboveEth is ETH.

Valid structured example

{ type: 'sellFee', percent: 2 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The validator rejects percent below 0 or above 25. Allocations attached to sellFee are checked separately against the collected total.

Bounds. The validator enforces 0%–25%. The editor prevents negative input.

Conflicts. Allocations may draw from this fee and cannot total more than 100% of it.

Rejected or incomplete examples

Take 30% on sells.Recognized, then rejected because sell fees must be between 0% and 25%.

Behavior Score and current edge

SELL source, fee percentage, optional condition, and allocation branches.

Current edge. A sell fee is structured configuration, not an observed charge.

Frontend model only

Time

Time rules

feeChangeOverTimeFee change

Represents an instant or gradual buy/sell fee change after time or a volume threshold.

Recognized instruction examples

Lower the sell fee from 5% to 1% after 24 hours.

Start at 5% and lower it to 1% over 7 days.

Lower sell fees to 1% after $100K of volume.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'feeChangeOverTime', fee, fromPercent, toPercent, afterHours, changeMode?, overHours?, triggerVolumeUsd? }

Required: fee, fromPercent, toPercent, afterHours
Optional: changeMode, overHours, triggerVolumeUsd
Units: percent fields are percentage points; afterHours and overHours are hours; triggerVolumeUsd is US-dollar notional.

Valid structured example

{ type: 'feeChangeOverTime', fee: 'sell', fromPercent: 5, toPercent: 1, afterHours: 168, changeMode: 'instant' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. Different targets for the same fee side at the same afterHours are rejected. Target ranges, time ranges, and volume ranges are not otherwise checked.

Bounds. No dedicated target-fee or time/volume range check is currently enforced.

Conflicts. Different target values for the same fee side at the same afterHours are rejected.

Rejected or incomplete examples

Lower sell fees eventually.Rejected as unrecognized because a target value and supported time or volume trigger are missing.

Behavior Score and current edge

A NOW-to-THEN/ENDS rail with percentage and time or volume endpoint.

Current edge. Volume-triggered changes have no live volume source. Pronouns use the most recently parsed fee source.

Frontend model only

timedActivationTimed activation

Represents a named behavior beginning after a delay or remaining active for a duration.

Recognized instruction examples

Only use this rule for the first 24 hours.

Stop this reward after 7 days.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'timedActivation', afterHours, action, durationHours? }

Required: afterHours, action
Optional: durationHours
Units: afterHours and durationHours are hours; action is descriptive text.

Valid structured example

{ type: 'timedActivation', afterHours: 0, durationHours: 24, action: 'the previous rule is active' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. No time bound or cross-rule target validation exists because action is not a linked rule ID.

Bounds. No domain-specific time bounds.

Conflicts. The free-text action is not resolved to another rule, so cross-rule conflicts are not checked.

Rejected or incomplete examples

Start rewards later.Rejected as unrecognized because no supported action and duration pattern is present.

Behavior Score and current edge

A plain-language TIME statement.

Current edge. ‘Previous rule’ relationships are descriptive, not linked by ID. ‘Start staking rewards after…’ is currently consumed as an incomplete staking rule before the timing pattern runs.

Frontend model only

tradingOpenTrading open

Represents opening trading after launch or at a locally parsed date/time.

Recognized instruction examples

Open trading 30 minutes after launch.

Open trading tomorrow at 9am.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'tradingOpen', mode, afterMinutes?, dateTime? }

Required: mode
Optional: afterMinutes, dateTime
Units: afterMinutes is minutes; dateTime is an ISO timestamp derived from local runtime time.

Valid structured example

{ type: 'tradingOpen', mode: 'afterLaunch', afterMinutes: 30 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. No range, timezone, duplicate-rule, or scheduler validation exists.

Bounds. No scheduling-range or timezone validation.

Conflicts. Multiple open rules are not reconciled.

Rejected or incomplete examples

Open trading later.Rejected as unrecognized because no supported delay or date/time is present.

Behavior Score and current edge

A plain-language TIME statement.

Current edge. ‘Tomorrow’ is parsed using the visitor/server runtime date and local timezone; no scheduler exists.

Frontend model only

Destination

Destination rules

buybackBuyback allocation

Routes a fixed trade percentage or share of a collected fee toward buying a target ticker.

Recognized instruction examples

Use half of sell fees to buy back MOG.

Use 1% of every sell to buy back MOG.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'buyback', source, percent, targetTicker, shareOfFee?, destination? }

Required: source, percent, targetTicker
Optional: shareOfFee, destination
Units: percent is effective percentage points of a trade; shareOfFee is percent of the collected source fee.

Valid structured example

{ type: 'buyback', source: 'sellFee', percent: 1, shareOfFee: 50, targetTicker: 'MOG' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. A share above 100%, an effective amount above an existing fee, or combined allocations above 100% of one source is rejected.

Bounds. A share over 100% or combined source allocations over 100% is rejected.

Conflicts. Competes with other allocations from the same fee source.

Rejected or incomplete examples

Buy MOG back sometime.Rejected as unrecognized because it does not match a supported buyback instruction pattern.

Behavior Score and current edge

A fee branch labeled BUY {ticker}; an explicit burn rule may add a BURN terminal.

Current edge. Buyback does not imply burn. Destination is editable but not parsed from every sentence form.

Frontend model only

burnBurn

Represents burning a share of bought-back tokens or, in the data model, another supported source.

Recognized instruction examples

Burn everything bought back.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'burn', source, percent, shareOfBuyback? }

Required: source, percent
Optional: shareOfBuyback
Units: percent and shareOfBuyback are percentages of the configured source.

Valid structured example

{ type: 'burn', source: 'buyback', percent: 100, shareOfBuyback: 100 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. There is no burn-specific numeric bound or relationship error today; the parser requires explicit burn language.

Bounds. No burn-specific numeric range is validated today.

Conflicts. No explicit conflict check.

Rejected or incomplete examples

Destroy some supply later.Rejected as unrecognized; a supported burn phrase must explicitly identify tokens or bought-back tokens.

Behavior Score and current edge

Appears as a BURN terminal only when an active buyback and explicit buyback-sourced burn both exist.

Current edge. The parser requires burn language and never infers burn from a buyback alone.

Frontend model only

holderRewardsHolder rewards

Allocates a fee share or trade percentage to holders.

Recognized instruction examples

Send half of sell fees to holders.

Share 1% of every trade with holders.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'holderRewards', source, percent, shareOfFee?, activationHours? }

Required: source, percent
Optional: shareOfFee, activationHours
Units: percent is effective trade percentage; shareOfFee is percent of the collected source; activationHours is hours.

Valid structured example

{ type: 'holderRewards', source: 'sellFee', percent: 1, shareOfFee: 50 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. Fee-share allocations participate in the per-source 100% total. Eligibility and distribution are not validated.

Bounds. Fee-share allocation totals cannot exceed 100%.

Conflicts. Shares the selected fee source with other allocations.

Rejected or incomplete examples

Reward the community.Rejected as unrecognized because neither a supported holder destination nor a measurable allocation is present.

Behavior Score and current edge

A fee branch labeled HOLDERS with its effective trade percentage.

Current edge. Eligibility, accounting, and distribution are not implemented.

Frontend model only

stakingRewardsStaking rewards

Allocates a fee share or trade percentage to stakers.

Recognized instruction examples

Send 25% of sell fees to stakers.

Send 1% of every sell to people who stake.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'stakingRewards', source, percent, shareOfFee?, activationHours? }

Required: source, percent
Optional: shareOfFee, activationHours
Units: percent is effective trade percentage; shareOfFee is percent of the collected source; activationHours is hours.

Valid structured example

{ type: 'stakingRewards', source: 'sellFee', percent: 1, shareOfFee: 50 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. Fee-share allocations participate in the per-source 100% total. A vague staking sentence is marked incomplete.

Bounds. Fee-share allocation totals cannot exceed 100%.

Conflicts. Shares the selected fee source with other allocations.

Rejected or incomplete examples

Reward stakers.Recognized but incomplete because the reward source or allocation is missing.

Behavior Score and current edge

A fee branch labeled STAKERS with its effective trade percentage.

Current edge. A vague staking-reward sentence is marked incomplete. Real staking and reward distribution are disabled.

Frontend model only

liquidityAllocationLiquidity allocation

Allocates a share of collected fees to the concept of growing liquidity.

Recognized instruction examples

Use 20% of collected fees to grow liquidity.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'liquidityAllocation', source, percent, shareOfFee? }

Required: source, percent
Optional: shareOfFee
Units: percent is effective trade percentage; shareOfFee is percent of the collected source.

Valid structured example

{ type: 'liquidityAllocation', source: 'sellFee', percent: 0.4, shareOfFee: 20 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The share participates in the source-fee 100% allocation total. No pool or liquidity action is verified.

Bounds. Fee-share allocation totals cannot exceed 100%.

Conflicts. Shares the selected fee source with other allocations.

Rejected or incomplete examples

Grow liquidity from fees.Rejected as unrecognized because a numeric share is missing.

Behavior Score and current edge

A fee branch labeled LIQUIDITY with effective percentage.

Current edge. Classic LP compounding is canonical strategy behavior, not this rule. No rule-controlled LP action, slippage handling, or custody path exists.

Frontend model only

liquidityProviderRewardsLiquidity-provider rewards

Allocates a share of collected fees to liquidity providers.

Recognized instruction examples

Send 20% of fees to liquidity providers.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'liquidityProviderRewards', source, percent, shareOfFee? }

Required: source, percent
Optional: shareOfFee
Units: percent is effective trade percentage; shareOfFee is percent of the collected source.

Valid structured example

{ type: 'liquidityProviderRewards', source: 'sellFee', percent: 0.4, shareOfFee: 20 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The share participates in the source-fee 100% allocation total. Provider eligibility is not validated.

Bounds. Fee-share allocation totals cannot exceed 100%.

Conflicts. Shares the selected fee source with other allocations.

Rejected or incomplete examples

Reward liquidity providers.Rejected as unrecognized because a numeric share and fee source are not expressed.

Behavior Score and current edge

A fee branch labeled LIQUIDITY PROVIDERS.

Current edge. Provider eligibility and reward accounting are not implemented.

Frontend model only

Milestone

Milestone rules

buyerRewardsBuyer milestone reward

Represents a reward for every Nth buyer, the first N buyers, or every buyer.

Recognized instruction examples

Reward every 100th buyer with 1,000 MOG.

Reward the first 100 buyers with 10 MOG.

Give every buyer 10 points.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'buyerRewards', mode, everyNthBuyer?/firstBuyers?, rewardType?, rewardAmount?, rewardTicker?, reward }

Required: reward plus the count implied by mode
Optional: reward type, amount, ticker until completed
Units: buyer counts are whole-event intervals; rewardAmount uses token units or points according to rewardType.

Valid structured example

{ type: 'buyerRewards', mode: 'everyNth', everyNthBuyer: 100, rewardType: 'token', rewardAmount: 1000, rewardTicker: 'MOG' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. A missing reward amount is marked incomplete. No maximum buyer count or reward amount is enforced.

Bounds. No numeric upper bound; missing reward amount is marked incomplete.

Conflicts. No cross-milestone conflict check.

Rejected or incomplete examples

Reward every 100th buyer.Recognized but incomplete because the reward amount is missing.

Behavior Score and current edge

A numbered milestone track ending at the configured buyer count and reward.

Current edge. ‘Reward every 100th buyer’ parses but cannot be locally created until an amount is supplied.

Frontend model only

Liquidity

Liquidity rules

liquidityLockLiquidity lock

Represents a period during which liquidity removal should not be allowed.

Recognized instruction examples

Lock liquidity for 30 days.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'liquidityLock', durationDays }

Required: durationDays
Optional: none
Units: durationDays is calendar-day duration in the frontend model.

Valid structured example

{ type: 'liquidityLock', durationDays: 30 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The editor prevents negative input. The validator has no maximum and does not compare the lock with early-removal rules.

Bounds. The editor prevents negative input; no maximum or deployment-level check exists.

Conflicts. No explicit conflict check with early-removal behavior.

Rejected or incomplete examples

Lock liquidity.Rejected as unrecognized because the duration is missing.

Behavior Score and current edge

A plain-language LIQUIDITY statement.

Current edge. No lock contract, custody mechanism, or enforcement exists.

Frontend model only

earlyLiquidityRemovalFeeEarly liquidity-removal fee

Represents a fee when liquidity is removed before a configured day threshold.

Recognized instruction examples

Charge 5% if liquidity is removed before 30 days.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'earlyLiquidityRemovalFee', percent, beforeDays }

Required: percent, beforeDays
Optional: none
Units: percent is percentage points; beforeDays is a day threshold.

Valid structured example

{ type: 'earlyLiquidityRemovalFee', percent: 5, beforeDays: 30 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. No dedicated percentage or duration bound and no conflict check against a liquidity lock exist today.

Bounds. No domain-specific fee maximum is currently validated.

Conflicts. No explicit conflict check with liquidity lock.

Rejected or incomplete examples

Charge a fee for early liquidity removal.Rejected as unrecognized because the percentage and day threshold are missing.

Behavior Score and current edge

A plain-language LIQUIDITY statement.

Current edge. The current app cannot observe or charge liquidity removal.

Frontend model only

Limit

Limit rules

maximumBuyMaximum buy

Represents a per-buy maximum in supply percent, token amount, or ETH, optionally for an early window.

Recognized instruction examples

Nobody can buy more than 1% of supply at once.

Nobody can buy more than 1 ETH at once.

Limit buys to 1% of supply for the first hour.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'maximumBuy', percentOfSupply, amount?, unit?, durationMinutes? }

Required: percentOfSupply (legacy/canonical field)
Optional: amount, unit, durationMinutes
Units: amount uses the selected unit: percent of supply, token units, or ETH; durationMinutes is minutes.

Valid structured example

{ type: 'maximumBuy', percentOfSupply: 1, amount: 1, unit: 'supplyPercent' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. A supply-percent maximum above maxWallet produces a warning. There is no domain-specific maximum.

Bounds. No upper bound; editor prevents negative input.

Conflicts. Warns when a supply-percent max buy exceeds max wallet.

Rejected or incomplete examples

Limit large buys during launch.Recognized with placeholder values but marked incomplete because the limit is unspecified.

Behavior Score and current edge

MAX BUY value and unit.

Current edge. ETH/token units leave percentOfSupply at 0 for storage compatibility.

Frontend model only

maximumSellMaximum sell

Represents a per-sell maximum in supply percent, token amount, or ETH, optionally for an early window.

Recognized instruction examples

Nobody can sell more than 0.5% of supply at once.

Limit sells to 0.5% of supply for the first day.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'maximumSell', percentOfSupply, amount?, unit?, durationMinutes? }

Required: percentOfSupply (legacy/canonical field)
Optional: amount, unit, durationMinutes
Units: amount uses the selected unit: percent of supply, token units, or ETH; durationMinutes is minutes.

Valid structured example

{ type: 'maximumSell', percentOfSupply: 0.5, amount: 0.5, unit: 'supplyPercent' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. No maximum-sell bound or cross-limit conflict is implemented; the editor prevents negative input.

Bounds. No upper bound; editor prevents negative input.

Conflicts. No explicit cross-limit conflict check.

Rejected or incomplete examples

Limit sells.Rejected as unrecognized because an amount and unit are missing.

Behavior Score and current edge

MAX SELL value and unit.

Current edge. A Classic pool and Uniswap route do not enforce this stored limit.

Frontend model only

maxWalletMaximum wallet

Represents a maximum percentage of total supply that one wallet may hold.

Recognized instruction examples

No wallet can hold more than 2% of supply.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'maxWallet', percentOfSupply }

Required: percentOfSupply
Optional: none
Units: percentOfSupply is percentage points of total supply.

Valid structured example

{ type: 'maxWallet', percentOfSupply: 2 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. A lower maxWallet than maximumBuy produces a warning. No upper bound is implemented.

Bounds. No upper bound; editor prevents negative input.

Conflicts. Warns when a maximum buy could exceed this wallet limit.

Rejected or incomplete examples

Keep wallet holdings small.Rejected as unrecognized because a percentage is missing.

Behavior Score and current edge

MAX WALLET percentage of supply.

Current edge. No wallet balances or transfer enforcement are connected.

Frontend model only

minimumTradeMinimum trade

Represents a minimum buy, sell, or both in ETH or token units.

Recognized instruction examples

Don't allow buys below 0.01 ETH.

No trades below 100 tokens.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'minimumTrade', amount, asset, side }

Required: amount, asset, side
Optional: none
Units: amount is ETH or token units; side is buy, sell, or both.

Valid structured example

{ type: 'minimumTrade', amount: 0.01, asset: 'ETH', side: 'buy' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The editor prevents negative input. No upper bound or comparison with maximum-trade rules exists.

Bounds. No domain-specific upper bound; editor prevents negative input.

Conflicts. No explicit check against maximum trade rules.

Rejected or incomplete examples

Block tiny trades.Rejected as unrecognized because a side, amount, and unit are missing.

Behavior Score and current edge

MIN BUY, MIN SELL, or MIN BOTH with asset.

Current edge. The stored minimum is not passed to or enforced by Classic routing.

Frontend model only

cooldownTrade cooldown

Represents a wait between repeated buys, sells, or trades by the same wallet.

Recognized instruction examples

Wait 30 seconds before the same wallet can sell again.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'cooldown', seconds, action }

Required: seconds, action
Optional: none
Units: seconds is elapsed wall-clock seconds; action is buy, sell, or trade.

Valid structured example

{ type: 'cooldown', seconds: 30, action: 'sell' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The editor prevents negative input. No maximum or relationship to another timing rule is checked.

Bounds. No maximum; editor prevents negative input.

Conflicts. No explicit conflict check.

Rejected or incomplete examples

Add a cooldown between sells.Rejected as unrecognized because a duration is missing.

Behavior Score and current edge

Action cooldown and seconds.

Current edge. Wallet identity and action history are not connected.

Frontend model only

Access

Access rules

accessRestrictionAccess restriction

Represents approved-wallet, token-holder, or NFT-holder access for buying, trading, or adding liquidity.

Recognized instruction examples

Only approved wallets can buy.

Only holders of TOKEN can trade.

Only holders of PASS NFT can buy.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'accessRestriction', requirement, action?, accessType?, tokenTicker? }

Required: requirement
Optional: action, accessType, tokenTicker
Units: No numeric unit. requirement and action are labels; tokenTicker is an identifier.

Valid structured example

{ type: 'accessRestriction', requirement: 'approved wallets', action: 'buy', accessType: 'approvedWallets' }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. No allowlist contents, balance, token standard, ownership, or composition of multiple restrictions is validated.

Bounds. No list, balance, token-standard, or ownership validation.

Conflicts. Multiple access rules are not composed or checked for contradiction.

Rejected or incomplete examples

Only selected wallets can buy.Rejected as unrecognized because ‘selected’ does not map to the supported approved-wallet pattern.

Behavior Score and current edge

A plain-language ACCESS statement.

Current edge. ‘Approved wallets’ has no list editor or onchain source today.

Frontend model only

Protection

Protection rules

volatilityProtectionVolatility protection

Represents pausing sells after a configured price move within a time window.

Recognized instruction examples

Increase protection when price moves too quickly.

These examples are parser fixtures, not an exhaustive grammar.

Normalized representation

{ type: 'volatilityProtection', movePercent, windowMinutes, pauseMinutes }

Required: movePercent, windowMinutes, pauseMinutes
Optional: none
Units: movePercent is percentage points; windowMinutes and pauseMinutes are minutes.

Valid structured example

{ type: 'volatilityProtection', movePercent: 10, windowMinutes: 5, pauseMinutes: 5 }

The structured object—not the sentence—is what the current frontend reviews, stores, and visualizes.

Validation and relationships

Implemented validation. The natural-language pattern inserts placeholder thresholds and marks the rule incomplete. No oracle or domain-specific bounds exist.

Bounds. The natural-language pattern inserts 10% / 5 min / 5 min defaults and marks thresholds incomplete; no domain-specific validation exists.

Conflicts. No oracle, fee, or other protection conflicts are checked.

Rejected or incomplete examples

Pause sells when volatility spikes.Recognized only as an incomplete volatility rule; thresholds must be completed in the editor.

Behavior Score and current edge

A plain-language PROTECTION statement.

Current edge. The broad phrase is intentionally incomplete; there is no price oracle or pause mechanism.

Frontend model only