Rule reference
Inspect every structured rule type supported by the current parser and manual catalog.
Documentation index
Fee rules
buyFeeBuy feeRepresents a percentage taken from buys, optionally for an early window or only above an ETH amount.
+
Accepted examples
Take 1% on buys.
Charge 4% on buys above 1 ETH.
Take 3% on buys for the first hour.
Normalized representation
{ type: 'buyFee', percent, durationMinutes?, aboveEth? }- Required
- percent
- Optional
- durationMinutes, aboveEth
Checks and relationships
Bounds. The validator enforces 0%–25%. The editor prevents negative input.
Conflicts. No direct duplicate-side conflict check; exact duplicate objects are normalized away.
What the reader sees
BUY source, fee percentage, and optional FIRST/ABOVE condition.
Current edge. Large-trade and temporary conditions are represented but not executed today.
sellFeeSell feeRepresents a percentage taken from sells, optionally for an early window or only above an ETH amount.
+
Accepted examples
Take 2% on sells.
Charge 4% on sells above 1 ETH.
Take 5% on sells for the first 24 hours.
Normalized representation
{ type: 'sellFee', percent, durationMinutes?, aboveEth? }- Required
- percent
- Optional
- durationMinutes, aboveEth
Checks and relationships
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.
What the reader sees
SELL source, fee percentage, optional condition, and allocation branches.
Current edge. A sell fee is structured configuration, not an observed charge.
Time rules
feeChangeOverTimeFee changeRepresents an instant or gradual buy/sell fee change after time or a volume threshold.
+
Accepted 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.
Normalized representation
{ type: 'feeChangeOverTime', fee, fromPercent, toPercent, afterHours, changeMode?, overHours?, triggerVolumeUsd? }- Required
- fee, fromPercent, toPercent, afterHours
- Optional
- changeMode, overHours, triggerVolumeUsd
Checks and relationships
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.
What the reader sees
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.
timedActivationTimed activationRepresents a named behavior beginning after a delay or remaining active for a duration.
+
Accepted examples
Start staking rewards after 24 hours.
Only use this rule for the first 24 hours.
Normalized representation
{ type: 'timedActivation', afterHours, action, durationHours? }- Required
- afterHours, action
- Optional
- durationHours
Checks and relationships
Bounds. No domain-specific time bounds.
Conflicts. The free-text action is not resolved to another rule, so cross-rule conflicts are not checked.
What the reader sees
A plain-language TIME statement.
Current edge. ‘Previous rule’ relationships are descriptive, not linked by ID.
tradingOpenTrading openRepresents opening trading after launch or at a locally parsed date/time.
+
Accepted examples
Open trading 30 minutes after launch.
Open trading tomorrow at 9am.
Normalized representation
{ type: 'tradingOpen', mode, afterMinutes?, dateTime? }- Required
- mode
- Optional
- afterMinutes, dateTime
Checks and relationships
Bounds. No scheduling-range or timezone validation.
Conflicts. Multiple open rules are not reconciled.
What the reader sees
A plain-language TIME statement.
Current edge. ‘Tomorrow’ is parsed using the visitor/server runtime date and local timezone; no scheduler exists.
Destination rules
buybackBuyback allocationRoutes a fixed trade percentage or share of a collected fee toward buying a target ticker.
+
Accepted examples
Use half of sell fees to buy back MOG.
Use 1% of every sell to buy back MOG.
Normalized representation
{ type: 'buyback', source, percent, targetTicker, shareOfFee?, destination? }- Required
- source, percent, targetTicker
- Optional
- shareOfFee, destination
Checks and relationships
Bounds. A share over 100% or combined source allocations over 100% is rejected.
Conflicts. Competes with other allocations from the same fee source.
What the reader sees
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.
burnBurnRepresents burning a share of bought-back tokens or, in the data model, another supported source.
+
Accepted examples
Burn everything bought back.
Normalized representation
{ type: 'burn', source, percent, shareOfBuyback? }- Required
- source, percent
- Optional
- shareOfBuyback
Checks and relationships
Bounds. No burn-specific numeric range is validated today.
Conflicts. No explicit conflict check.
What the reader sees
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.
holderRewardsHolder rewardsAllocates a fee share or trade percentage to holders.
+
Accepted examples
Send half of sell fees to holders.
Share 1% of every trade with holders.
Normalized representation
{ type: 'holderRewards', source, percent, shareOfFee?, activationHours? }- Required
- source, percent
- Optional
- shareOfFee, activationHours
Checks and relationships
Bounds. Fee-share allocation totals cannot exceed 100%.
Conflicts. Shares the selected fee source with other allocations.
What the reader sees
A fee branch labeled HOLDERS with its effective trade percentage.
Current edge. Eligibility, accounting, and distribution are not implemented.
stakingRewardsStaking rewardsAllocates a fee share or trade percentage to stakers.
+
Accepted examples
Send 25% of sell fees to stakers.
Send 1% of every sell to people who stake.
Normalized representation
{ type: 'stakingRewards', source, percent, shareOfFee?, activationHours? }- Required
- source, percent
- Optional
- shareOfFee, activationHours
Checks and relationships
Bounds. Fee-share allocation totals cannot exceed 100%.
Conflicts. Shares the selected fee source with other allocations.
What the reader sees
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.
liquidityAllocationLiquidity allocationAllocates a share of collected fees to the concept of growing liquidity.
+
Accepted examples
Use 20% of collected fees to grow liquidity.
Normalized representation
{ type: 'liquidityAllocation', source, percent, shareOfFee? }- Required
- source, percent
- Optional
- shareOfFee
Checks and relationships
Bounds. Fee-share allocation totals cannot exceed 100%.
Conflicts. Shares the selected fee source with other allocations.
What the reader sees
A fee branch labeled LIQUIDITY with effective percentage.
Current edge. No pool, LP action, slippage handling, or custody path exists.
liquidityProviderRewardsLiquidity-provider rewardsAllocates a share of collected fees to liquidity providers.
+
Accepted examples
Send 20% of fees to liquidity providers.
Normalized representation
{ type: 'liquidityProviderRewards', source, percent, shareOfFee? }- Required
- source, percent
- Optional
- shareOfFee
Checks and relationships
Bounds. Fee-share allocation totals cannot exceed 100%.
Conflicts. Shares the selected fee source with other allocations.
What the reader sees
A fee branch labeled LIQUIDITY PROVIDERS.
Current edge. Provider eligibility and reward accounting are not implemented.
Milestone rules
buyerRewardsBuyer milestone rewardRepresents a reward for every Nth buyer, the first N buyers, or every buyer.
+
Accepted examples
Reward every 100th buyer with 1,000 MOG.
Reward the first 100 buyers with 10 MOG.
Give every buyer 10 points.
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
Checks and relationships
Bounds. No numeric upper bound; missing reward amount is marked incomplete.
Conflicts. No cross-milestone conflict check.
What the reader sees
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.
Liquidity rules
liquidityLockLiquidity lockRepresents a period during which liquidity removal should not be allowed.
+
Accepted examples
Don't allow liquidity to be removed for 30 days.
Normalized representation
{ type: 'liquidityLock', durationDays }- Required
- durationDays
- Optional
- none
Checks and relationships
Bounds. The editor prevents negative input; no maximum or deployment-level check exists.
Conflicts. No explicit conflict check with early-removal behavior.
What the reader sees
A plain-language LIQUIDITY statement.
Current edge. No lock contract, custody mechanism, or enforcement exists.
earlyLiquidityRemovalFeeEarly liquidity-removal feeRepresents a fee when liquidity is removed before a configured day threshold.
+
Accepted examples
Charge 5% if liquidity is removed before 30 days.
Normalized representation
{ type: 'earlyLiquidityRemovalFee', percent, beforeDays }- Required
- percent, beforeDays
- Optional
- none
Checks and relationships
Bounds. No domain-specific fee maximum is currently validated.
Conflicts. No explicit conflict check with liquidity lock.
What the reader sees
A plain-language LIQUIDITY statement.
Current edge. The current app cannot observe or charge liquidity removal.
Limit rules
maximumBuyMaximum buyRepresents a per-buy maximum in supply percent, token amount, or ETH, optionally for an early window.
+
Accepted 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.
Normalized representation
{ type: 'maximumBuy', percentOfSupply, amount?, unit?, durationMinutes? }- Required
- percentOfSupply (legacy/canonical field)
- Optional
- amount, unit, durationMinutes
Checks and relationships
Bounds. No upper bound; editor prevents negative input.
Conflicts. Warns when a supply-percent max buy exceeds max wallet.
What the reader sees
MAX BUY value and unit.
Current edge. ETH/token units leave percentOfSupply at 0 for storage compatibility.
maximumSellMaximum sellRepresents a per-sell maximum in supply percent, token amount, or ETH, optionally for an early window.
+
Accepted examples
Nobody can sell more than 0.5% of supply at once.
Limit sells to 0.5% of supply for the first day.
Normalized representation
{ type: 'maximumSell', percentOfSupply, amount?, unit?, durationMinutes? }- Required
- percentOfSupply (legacy/canonical field)
- Optional
- amount, unit, durationMinutes
Checks and relationships
Bounds. No upper bound; editor prevents negative input.
Conflicts. No explicit cross-limit conflict check.
What the reader sees
MAX SELL value and unit.
Current edge. A stored limit is not enforced by current trading, which is disabled.
maxWalletMaximum walletRepresents a maximum percentage of total supply that one wallet may hold.
+
Accepted examples
No wallet can hold more than 2% of supply.
Normalized representation
{ type: 'maxWallet', percentOfSupply }- Required
- percentOfSupply
- Optional
- none
Checks and relationships
Bounds. No upper bound; editor prevents negative input.
Conflicts. Warns when a maximum buy could exceed this wallet limit.
What the reader sees
MAX WALLET percentage of supply.
Current edge. No wallet balances or transfer enforcement are connected.
minimumTradeMinimum tradeRepresents a minimum buy, sell, or both in ETH or token units.
+
Accepted examples
Don't allow buys below 0.01 ETH.
No trades below 100 tokens.
Normalized representation
{ type: 'minimumTrade', amount, asset, side }- Required
- amount, asset, side
- Optional
- none
Checks and relationships
Bounds. No domain-specific upper bound; editor prevents negative input.
Conflicts. No explicit check against maximum trade rules.
What the reader sees
MIN BUY, MIN SELL, or MIN BOTH with asset.
Current edge. Token decimals and quote conversion are not modeled.
cooldownTrade cooldownRepresents a wait between repeated buys, sells, or trades by the same wallet.
+
Accepted examples
Wait 30 seconds before the same wallet can sell again.
Normalized representation
{ type: 'cooldown', seconds, action }- Required
- seconds, action
- Optional
- none
Checks and relationships
Bounds. No maximum; editor prevents negative input.
Conflicts. No explicit conflict check.
What the reader sees
Action cooldown and seconds.
Current edge. Wallet identity and action history are not connected.
Access rules
accessRestrictionAccess restrictionRepresents approved-wallet, token-holder, or NFT-holder access for buying, trading, or adding liquidity.
+
Accepted examples
Only approved wallets can buy.
Only holders of TOKEN can trade.
Only holders of PASS NFT can buy.
Normalized representation
{ type: 'accessRestriction', requirement, action?, accessType?, tokenTicker? }- Required
- requirement
- Optional
- action, accessType, tokenTicker
Checks and relationships
Bounds. No list, balance, token-standard, or ownership validation.
Conflicts. Multiple access rules are not composed or checked for contradiction.
What the reader sees
A plain-language ACCESS statement.
Current edge. ‘Approved wallets’ has no list editor or onchain source today.
Protection rules
volatilityProtectionVolatility protectionRepresents pausing sells after a configured price move within a time window.
+
Accepted examples
Increase protection when price moves too quickly.
Normalized representation
{ type: 'volatilityProtection', movePercent, windowMinutes, pauseMinutes }- Required
- movePercent, windowMinutes, pauseMinutes
- Optional
- none
Checks and relationships
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.
What the reader sees
A plain-language PROTECTION statement.
Current edge. The broad phrase is intentionally incomplete; there is no price oracle or pause mechanism.