Base

Creating pools with DeliHook and DeliHookConstantProduct allows for any ERC20 token to be paired with wBLT (also ERC20), and users can stream additional incentives with any of the underlying pool or additional universally whitelisted token. This whitelist for universal reward tokens is maintained by an owner address (multisig). However, only the standard tokens that are compatible with UniV4 are considered in scope of the contest (except Native ETH).

• Owner: trusted. Keeper: semi-trusted (can only flush buybacks; slippage/thresholds enforced); they should only be able to do what is described in the question about "off-chain mechanisms" and are trusted to do that correctly, but if they manage to do something else to harm the protocol/users, and it leads to High/medium impact, then it may be considered valid. Hooks: must be whitelisted; Adapter callers must be authorised; both are trusted.

• DeliHook (V4)

  • setFeeProcessor/setDailyEpochGauge/setIncentiveGauge: non-zero address.
  • setPoolFee: 0.01%–3.00% inclusive (100–30,000 pips of 1,000,000).

• DeliHookConstantProduct (V2)

  • setFeeProcessor/setDailyEpochGauge/setIncentiveGauge/setV2PositionHandler: non-zero address.

• FeeProcessor

  • setBuybackBps: 0–10,000.
  • setKeeper/setHook: non-zero address.
  • setBuybackPoolKey: pair must be (BMX, wBLT).
  • claimVoterFees: reverts if zero pending.
  • sweepERC20: token cannot be BMX or wBLT.
  • flushBuffer: buybackPoolSet must be true; per‑pool buffer ≥ 1e18 wBLT; keeper‑only.
  • flushBuffers: arrays must have equal length (no hard max; gas‑bounded).

• DailyEpochGauge

  • setFeeProcessor/setPositionManagerAdapter/setHook: non-zero address.

• IncentiveGauge

  • setHook/setPositionManagerAdapter: non-zero address.

• PositionManagerAdapter

  • addHandler: non-zero; handlerType must be unique.
  • removeHandler: handlerType must exist.
  • setGauges: non-zero addresses.

• Voter

  • setOptions: each option < 10,000 (BPS).
  • setSafetyModule/setDistributor/setAdmin: non-zero address.
  • deposit (admin): amount > 0; epoch must not be settled.
  • finalize (admin): epoch must have ended and not be settled; batch size unconstrained (gas‑bounded).

• Arrays/length limits

  • No explicit max lengths on any admin/role‑restricted array inputs. Length equality is checked where relevant (e.g., flushBuffers). All loops are gas‑bounded.

No

Not specifically

• Keepers are required for flushing buyback buffers in the FeeProcessor contract. They can read pending pool buffers that meet the required threshold and batch flush them, running on a pseudo-random interval cron job.
• Keeper/admin is required for finalizing voting epochs and claiming voter fees from the FeeProcessor to process to wETH and deposit in the Voter.

• DeliHook (V4)

  • All pools include wBLT; native ETH unsupported.
  • V4 pools use dynamic LP fees; V4 hook overrides PoolManager LP fee to 0 on swaps.
  • Fee derived strictly from tickSpacing mapping; unsupported spacings revert.
  • Owner-set per-pool dynamic fee stays within 0.01%–3.00%.
  • Fee forwarded equals computed fee (in wBLT); gauges are poked on every swap.

• DeliHookConstantProduct (V2)

  • All pools include wBLT; native ETH unsupported.
  • Pool init invariants: wBLT present, tickSpacing=1, sqrtPrice=2^96 (tick 0), fee ≥ 0.1%.
  • Constant-product math reflects reserves after fee extraction; reserves are uint128 and never overflow.
  • Shares accounting: first mint locks MINIMUM_LIQUIDITY; totalSupply mirrors user share mints/burns; one synthetic position per (pool, owner).
  • Fee currency is always wBLT; ERC‑6909 burn→take occurs before forwarding fees.
  • sqrtPriceLimitX96 enforced against virtual price from reserves.
  • Synthetic tokenIds always have bit 255 set (no collision with V4 NFTs).

• FeeProcessor

  • Split invariants: buybackPortion + voterPortion == collected amount; buybackBps ≤ 10,000.
  • Per-pool buyback buffers tracked exactly; pending pool set contains a pool if its buffer > 0; swap‑and‑pop indices remain consistent.
  • Buybacks only when buffer ≥ 1e18 wBLT and buyback pool is set; BMX out ≥ keeper-specified min.
  • Voter buffer only moves via claimVoterFees; cannot sweep BMX or wBLT; only whitelisted hooks can call collectFee.

• DailyEpochGauge

  • Day-bucket scheduling: additions on day N stream on day N+2; streamRate matches current day bucket / 86400.
  • Range-aware accrual only for liquidity inside tick range; pool/position accumulators are monotonic and time-synced.

• IncentiveGauge

  • Incentive schedules stream at constant rate; remaining never underflows; deactivates when finished.
  • Range-aware accrual only for liquidity inside tick range; pool/position accumulators are monotonic and time-synced.

• PositionManagerAdapter

  • Only PositionManager and authorized callers may invoke subscriber methods.
  • Handler types are unique; V2 fallback returns a valid PoolKey or reverts.
  • Total gas for notifyUnsubscribe does not exceed 300k (Uniswap v4 PositionManager gas limit for unsubscribe callback on Base is 300k)

• Handlers

  • V4PositionHandler reflects PositionManager state for ownership/liquidity.
  • V2PositionHandler: one synthetic tokenId per (pool, owner); liquidity never underflows; pool key stored by truncated id for adapter fallback.

• Voter

  • Weekly epoch must have ended and not been settled to finalize; nextEpochToFinalize advances monotonically over settled epochs.
  • Options each < 10,000 BPS; totalWeth at finalization equals toSafety + toRewards; distributor rate = toRewards / 1 week.
  • Auto-vote cannot be disabled during any in-flight finalization or when any ended epoch is unfinalized; manual votes override auto for that epoch.
  • Manual voter weights reconciled down if balances decreased at finalization.

• User rewards are intentionally forfeited in IncentiveGauge if a position is unsubscribed to fit within Uniswap v4's PositionManager gas limit. An admin function to "force unsubscribe" a position exists in both gauge contracts for added safety, and users will be informed of this design in documentation and on the UI.
• The Voter contracts will always have finalization of epochs done once available, as these are required for our protocol's overall fee/reward distributions.
• To make positions created in DeliHookConstantProduct pools compatible with the in-range reward accounting, they have full-range synthetic v4-style position structs created with V2PositionHandler.
• Internal swap flag passed in hookData for swaps from the FeeProcessor allows for future potential automated buybacks occurring on swaps.
• As DeliHook pools require using the dynamic fee flag when initializing, the fee is determined by the pool's tick spacing. This can be updated post-initialization with an admin function.
• If a pool generates less than the required wBLT fee threshold, no buyback and transfer to the DailyEpochGauge for streaming will occur.

• User rewards are intentionally forfeited in IncentiveGauge if a position is unsubscribed to fit within Uniswap v4's PositionManager gas limit.
• Aside from the manual reward token whitelist, the underlying pool tokens (token A and wBLT) are always allowed to be used as incentive tokens. Any malicious underlying/reward token risk is accepted as long as it is isolated to only that pool.
• Batch functions in the contracts are gas-bounded; oversized batches can run out of gas and should be split up by operator

All documentation is in the repository README files.

The in-scope contracts will interact with these already deployed contracts (on Base):
RewardDistributor: 0x0259083181ae54730f4fbb1c174a53e21bce5266
BMX: 0x548f93779fBC992010C07467cBaf329DD5F059B7
wBLT: 0x4E74D4Db6c0726ccded4656d0BCE448876BB4C7A
sbfBMX: 0x38E5be3501687500E6338217276069d16178077E

They will also be referred to in the Judging Phase.