Rules the hook can enforce.
Each module below is implemented in the transfer hook or explicitly rejected at lock. Social metrics are triggers, not transfer rules.
Fair launchMax wallet
Rejects a transfer when the destination token account would hold more than the stage's basis points of supply.
The hook reads the destination balance after Token-2022 has applied the transfer. If the hook rejects, the whole transfer reverts. Sells into the configured pool vault are exempt so the curve can hold inventory. The cap is per token account, not the sum of every account a wallet controls. Splitting across accounts is outside what a transfer hook can see.
Trading compatibility
Any route that includes the hook accounts. A route that strips them cannot move the token.
Open rule reference →Fair launchMax transfer
Rejects a single transfer above the stage's basis points of supply.
This applies to buys, sells, and wallet transfers. It does not know USD size. The parameter is an integer ratio of base supply.
Trading compatibility
Hook-aware routes during the stages where the rule is on.
Open rule reference →Fair launchSame-slot repeat buy
Stops the same wallet from buying twice in one slot through the bound pool vault.
A separate guard stores the last buy slot for each mint and wallet. Another buyer cannot reset it: A → B → A in one slot still rejects A's second buy. This is not a general bundle detector.
Trading compatibility
Only meaningful once a pool vault is bound. The rule is refused at lock if the vault is missing.
Open rule reference →TimeLaunch sell delay
Refuses sells into the pool until a delay of at most one hour has elapsed.
Buys still succeed. The program rejects a delay above 3600 seconds. The configurator shows this as a temporary sell restriction before lock.
Trading compatibility
Sells through the bound vault are refused during the delay. Wallet transfers are not treated as sells.
Open rule reference →TimeTrading window
Allows transfers only inside a UTC minute-of-day window.
A window that wraps past midnight is supported. Equal start and end are rejected because that encoding means the window is disabled.
Trading compatibility
Every transfer, including wallet to wallet, is inside the window or it fails.
Open rule reference →AccessAllowlist
Only listed wallets may receive tokens, except a sell into the pool vault.
Each stage stores up to eight addresses. The list is part of the configuration hash. It is not an anonymous-trading mode.
Trading compatibility
Buys require the recipient to be listed. Sells into the vault do not require the pool authority to be listed.
Open rule reference →AccessBlocklist
Listed wallets cannot be the user side of a buy, sell, or wallet transfer.
The pool authority is not treated as the user. Eight addresses per stage.
Trading compatibility
Hook-aware transfers.
Open rule reference →TransferPool only
Rejects wallet-to-wallet transfers.
Curve buys and sells still require a route that understands the hook. This rule cannot be combined with p2p-only.
Trading compatibility
EVOLVE route required. Wallet transfers fail.
Open rule reference →TransferP2P only
Rejects transfers that touch the bound pool vault.
Permanent mode only. Graduating mode refuses the rule at validation because it would block curve buys and sells.
Trading compatibility
Not compatible with Meteora DBC trading.
Open rule reference →