Rules

A vault holds up to ten rules. Each rule has a share in basis points, and the shares must add up to exactly 100%. Each rule owns a bucket: its part of every settled inflow, waiting to be paid out by the matching crank. Four kinds can be set by a manager; a fifth, Forward, appears on its own when a social escrow expires.

Validation at set_rules: shares sum to 10,000 bps, drip period at least 60 seconds, social claim window one of 7 / 14 / 30 / 90 / 365 days, a fallback rule must be a Wallet, Drip or Buyback rule in the same set, buyback impact between 1 and 50 bps.

Wallet

The simplest rule: a share to any address. Team, treasury, a charity, a market maker, a multisig. For SOL quotes the keeper pays only once the destination would be rent-exempt after the credit; for token quotes it creates the recipient's token account if it does not exist (the keeper pays that rent).

Dump Shield drip

While market cap is below X, holders receive Y% of this rule's bucket every N minutes, pro-rata to supply.

Parameters: max_mcap_quote (0 = always on), bps_per_period, period_secs (≥ 60), min_holding_quote (0 = no minimum).

Epochs. When a period has passed, the next drip opens a new epoch with epoch_budget = bucket × Y%. The keeper then pays holders in batches that fit one transaction (about 14 holders for SOL quotes, 9 for token quotes), resuming from a cursor until the budget is spent. The cursor advances strictly by owner address, so no holder can be paid twice in an epoch.

Who counts as a holder. Only real wallets: the token account must be the owner's associated token account for the coin, the owner must be a system-owned, on-curve address. Pools, lockers, program-derived addresses and programs are excluded on chain, not by a list. Holders whose position is worth less than min_holding_quote (valued at the current pool price) are skipped.

Pro-rata to circulating supply. payout = epoch_budget × holder_amount / circulating, where circulating is the mint supply minus what the bonding curve (or the pool) holds. Because the denominator is the full circulating supply, leaving holders out of a batch can never inflate anyone else's share.

The market-cap line. Market cap is read from the pump.fun bonding curve (virtual reserves) until the coin migrates, then from the canonical PumpSwap pool. If mcap ≥ max_mcap_quote the drip instruction fails with DripConditionNotMet and nothing is paid; the bucket keeps growing until the price falls under the line again. The token page shows "Dump Shield active" or "idle" from the same price source.

Skipped payouts. Credits that would leave an empty wallet below rent, or holders without a quote token account (token-quoted coins), are skipped; the cursor still advances and the money stays in the bucket for the next epoch.

Buyback & Burn

The bucket buys the coin on pump.fun in small, impact-capped steps and burns everything it receives in the same transaction.

Parameters: max_mcap_quote (0 = always on), max_impact_bps (1–50, that is at most 0.5% price impact per purchase).

Venue. The bonding curve until the coin migrates, then the canonical PumpSwap pool. The program builds pump.fun's buy instruction itself (buy_exact_sol_in, buy_exact_quote_in_v3 or PumpSwap's buy_exact_quote_in_v2), so a crank cannot smuggle in a different instruction, and it checks that the user, mint, token account and curve or pool accounts belong to this vault.

Spend per call is the smallest of: the crank's spend cap, the bucket, quote_reserve × max_impact_bps / 10 000, and what the vault can afford after rent. The low impact cap keeps a sandwich attack around the buy unprofitable at pump.fun's fee levels.

Floor. The program computes the constant-product output on the pre-trade reserves and requires at least 95% of it (the 5% tolerance covers pump.fun fees); the keeper passes a tighter 3% floor. Every token received is burned in the same instruction. The rule's tokens_burned grows and the token page shows it as a share of supply.

A system-owned buyer account derived from the vault fronts the purchase, because pump.fun moves SOL from the buyer with the system program. Whatever it holds above its entry balance returns to the vault in the same instruction, so the vault's measured spend is exactly what pump.fun took.

Social escrow

A share for an X or GitHub account that may not have a wallet yet. Released by signing in; falls back on chain after 7 to 365 days.

Parameters: platform (X or GitHub), user_id (the account's numeric id, which never changes even if the handle does), a claim window (7, 14, 30, 90 or 365 days) and a fallback: either a wallet or another rule in the vault.

• The rules editor resolves a handle to its numeric id through the Feebric verifier.
• The share accrues into the escrow's bucket from day one. The token page shows it as Unclaimed with the deadline and a claim link.
• The account owner claims by signing in; see Claiming an escrow. The claim sends the bucket to the recipient they choose and turns the rule into a Wallet rule for that recipient, so future shares go straight there with no further logins.
• If nobody claims before the deadline, expire_social turns the rule into a Wallet rule for the fallback wallet or into a Forward rule into the fallback rule, and moves the bucket there.
• Changing the rules of an unlocked vault gives social escrows fresh claim windows.

Forward

Created only by expire_social when the fallback is another rule. At settlement, a Forward rule's share is pushed straight into its target, and the token page shows it as "→ rule #n".