Protocol security specification

This specification defines implementation requirements for the current architecture. MUST and MUST NOT mark mandatory rules; SHOULD marks a recommendation, and MAY marks permission. For the contract guarantees and trust assumptions in plain language, see Security.

OTF supply

OTFToken MUST mint exactly 1,000,000,000 ether in its constructor, with no later mint path. ProtocolConstants.OTF_INITIAL_SUPPLY MUST remain fixed; totalSupply() MUST fall when a holder burns owned or approved tokens. Deployment MUST allocate 100 million OTF to team vesting, 200 million to the launch manager, and 700 million to the rewards distributor, leaving the deployer with zero OTF.

Canonical launch

The launch manager MUST create one OTF/WETH V4 pool with static fee 0 and tick spacing 1. It MUST initialize at the fixed square-root price for exactly 15 ETH reference FDV against original issuance.

The manager MUST use ProtocolConstants.OTF_INITIAL_SUPPLY without reading issuance from the token. The final tick MUST be -158188 when OTF is currency0 and 158188 when OTF is currency1, approximately 134.997562702653186573 ETH reference FDV. The next tick in the direction of increasing OTF price MUST exceed 135 ETH.

initializeLaunch() MUST remain permissionless and pull exactly REQUIRED_OTF_BALANCE (200 million OTF) from msg.sender after the phase and hook checks. The caller MUST supply the full balance and allowance; existing manager balances or donations MUST NOT reduce this transfer. Funding, pool initialization, and bootstrap liquidity creation MUST succeed in one transaction or revert together. Deployment MUST approve exactly this amount to the manager, then call initializeLaunch() from the funding wallet.

Liquidity MUST use these fixed values:

Tick boundaries and token amounts MUST use pinned V4 TickMath and SqrtPriceMath, rounding up mint requirements and down bootstrap removal. Bootstrap OTF MUST stay within 150 million and permanent OTF within 50 million. Derived bootstrap WETH principal MUST equal derived permanent WETH.

Reducing bootstrap liquidity by one MUST underfund that WETH principal. Increasing permanent liquidity by one MUST exceed the permanent OTF cap in both currency orderings.

The hook address MUST encode exactly beforeInitialize, beforeAddLiquidity, and afterSwap (0x2840), with no beforeSwap. Third-party pool initialization MUST revert, including before the predicted CREATE2 manager address has code.

Before Graduated, beforeAddLiquidity MUST require the immutable PoolManager, canonical pool, immutable PositionManager as sender, and active internal mint authorization. PositionManager identity alone MUST NOT authorize third-party mints.

Bootstrap authorization MUST require NotInitialized, ordered bootstrap ticks, and exactly BOOTSTRAP_LIQUIDITY. Permanent authorization MUST require GraduationReady, full-range ticks, and exactly PERMANENT_LIQUIDITY. Both deltas MUST be positive. Authorization MUST exist only during its synchronous mint call, clearing on success or rolling back on failure.

These checks reserve tick capacity for graduation. Once the permanent position exists and the phase is Graduated, external liquidity additions MUST be allowed. The permanent position MUST stay locked.

During bootstrap, afterSwap MUST reject prices outside the tick-derived boundaries. It MUST mark GraduationReady only at exact final sqrtPriceX96 equality and reject swaps while ready. After graduation, it MUST return without reading pool state.

The launch router MUST limit buys at the final boundary and sells at the initialization-side boundary. It MUST settle only consumed input, preserve unused WETH, refund unused ETH, and enforce minimum output and deadline. It MUST call permissionless finalization only after the PoolManager returns control. Finalization failure MUST revert the complete boundary purchase.

Native-output sells MUST unwrap only the current swap’s WETH output after settlement and send that ETH to the specified recipient under the reentrancy guard. A rejected payout MUST revert the sale. The launch router MUST accept callback ETH only from WETH and preserve pre-existing ETH and WETH.

Finalization MUST recompute amounts, remove the bootstrap position, and measure both returned tokens. The fixed full-range permanent position MUST receive only the derived WETH principal and at most 50 million OTF. Extra WETH MUST stay locked without changing position size.

After the permanent mint, the manager MUST burn its entire OTF balance once, including unsolicited OTF. It MUST retain the permanent NFT, with no callable path to remove, reprice, rebalance, migrate, or replace its principal.

Team vesting

Live FDV MUST use canonical V4 spot state, the configured ETH/USD answer, and current totalSupply(). Both currency orderings MUST produce the same economic price. Oracle answers MUST be positive, no older than maxOracleAge, and not from the future.

Checkpoints MUST make 10 million OTF claimable for each completed $1 million FDV milestone, capped at $10 million. Cumulative unlocks MUST NOT decrease. Claims MUST go to the current beneficiary and MUST NOT exceed unlocked OTF less prior claims.

Only the current beneficiary MAY checkpoint, claim, nominate a successor, or replace or cancel a pending nomination. A nonzero nominee MUST accept before receiving that authority. Acceptance MUST clear the nomination and preserve unlocked and claimed amounts. Beneficiary-only checkpointing requires trust in the beneficiary and MUST NOT be described as protection against spot-price manipulation.

Fund fees and accounted OTF

Annual creator expense, mint, and redeem rates MUST be immutable and capped at 1,000, 200, and 100 bps respectively. Mint fees MUST apply to all minting through the entry router. Redeem fees MUST apply to routed and direct in-kind redemption, except when the share owner is the configured collector. Collector redemptions and redemptions after shutdown MUST charge no redeem fee. Redemption previews MUST take the share owner and use the same fee exemption and integer arithmetic as execution.

While a vault is active, operations that change accounted OTF MUST checkpoint accrued annual fees first. Token donations MUST NOT change accounted balances or fee benefits. The creator share MUST be:

5000 bps + floor(4000 bps × sqrt(min(accounted OTF, 10m OTF) / 10m OTF))

The creator share MUST stay between 5,000 and 9,000 bps. Mint and redeem creator shares MUST round down; annual expense splits MUST carry fractional remainders across checkpoints.

The vault MUST mint both fee portions to the collector and record the split when charging each fee. Settlement MUST NOT recalculate that split from later accounted OTF.

The vault MUST NOT transfer constituent OTF to the collector merely because it is OTF.

Native entry and exit

OTFEntryExitRouter MUST store a nonzero immutable canonical WETH. Native mint MUST require nonzero amountIn and exact msg.value == amountIn; ERC-20 endpoints MUST reject native value. The router MUST wrap exactly the accepted ETH and use WETH for basket planning, vault calls, and adapter legs. It MUST refund the current operation’s unused WETH as ETH and other constituents as ERC-20 transfers.

Native redemption MUST route to canonical WETH, enforce the aggregate minimum, unwrap only the current operation’s output, and send exactly that ETH to the caller. Rejected ETH sends MUST revert the transaction.

The router MUST accept callback ETH only from canonical WETH, guard wrapping, unwrapping, sends, and refunds against reentrancy, clear temporary approvals, and preserve pre-existing or forcibly sent ETH and WETH. Native sentinels, zero addresses, and ETH MUST NOT reach vaults, SwapLegs, or adapters.

Buyback collector

The collector MUST accept fee accounting only from canonical vaults recognized by OTFFactory.isVault, without maintaining a second registry. Settlement MUST reject unrecognized vaults, read the vault’s immutable expense beneficiary, and allow only that beneficiary to settle.

Settlement MUST checkpoint annual fees and consume all recorded creator and buyback shares through one beneficiary-selected route: sell the combined shares through approved adapters to canonical WETH, or redeem them and liquidate every unskipped basket constituent to canonical WETH.

A share-sale route MUST consume the exact pending shares and leave only WETH from the operation. It MAY use intermediate tokens through approved adapters. Only the configured collector MAY call the entry router’s fee-share sale function. Each leg MUST name exact input and output tokens and a positive minimum output.

Settlement MUST enforce the caller’s deadline, aggregate WETH minimum, final OTF minimum, and observed WETH and OTF deltas. It MUST split actual WETH in proportion to stored fee shares and transfer the exact creator portion to the beneficiary. Only the buyback portion MAY purchase OTF. Fee settlement MUST NOT add an oracle, TWAP, route discovery, protocol fair-value floor, or hardcoded slippage.

The WETH-to-OTF swap MUST use the immutable canonical V4 pool key and burn all acquired OTF before success. The collector MUST NOT expose arbitrary calls, token withdrawals, rescue functions, or configurable final routes.

Cumulative rewards

The publisher MUST budget 700 million OTF over 208 weeks: 650 million for depositors and 50 million for fund creators. Week 1 MUST budget 13 million for depositors and 1 million for creators. Later weekly targets MUST decline by approximately 1.968%, following 14,000,000 × 0.9803203^(n - 1) with n starting at 1.

Each week’s budget MUST keep the 13-to-1 ratio, subject to integer rounding and final-week reconciliation. The schedule MUST NOT use monthly buckets, quarterly steps, or periodic halvings, or allocate emissions after week 208.

The shared schedule MUST round each weekly decay down to 18-decimal OTF units and reconcile the final week’s budgets to exactly 700 million OTF, including 650 million for depositors and 50 million for creators. These are budget totals. Actual allocations MAY be lower because of caps, eligibility, participant allocations, or rounding.

Both buckets MUST calculate each fund’s initial allowance in proportion to min(accounted protocol OTF balance, 10,000,000 OTF) per fund. Funds without accounted OTF MUST receive zero allocation. Balances above the cap and unaccounted OTF transfers MUST NOT increase weight. If total weight is zero, no fund MAY receive an allocation. The publisher MUST calculate weekly snapshot balances, participant entitlements within each fund’s allocation, rounding, and cumulative entitlements offchain before publishing.

Each fund’s weekly depositor allowance MUST be the smaller of its proportional allowance and snapshot NAV USD × (101^(1/52) − 1) ÷ chosen OTF price USD, rounded down to 18-decimal OTF units. This enforces a 10,000% depositor rewards APY cap with weekly compounding. Zero NAV MUST give zero depositor rewards. Creator rewards MUST retain their proportional allowance without this APY cap.

The publisher MUST supply one positive weekly average OTF USD price for all funds and record it in the artifact. Publication tooling MUST NOT substitute a market price. Snapshot NAV MUST remain the recorded valuation; the selected price values reward tokens. Missing valuation inputs MUST block generation. Excess and rounding dust MUST remain unallocated, without redistribution or automatic rollover.

Publication tooling MUST require weekly fund and participant increments, a complete snapshot fund roster, and the previous artifact after week one. It MUST reduce depositor increments proportionally when their total exceeds the allowance, round down, and add valid increments to prior cumulative entitlements. Creator increments MUST NOT exceed their fund’s proportional allowance. Tooling MUST reject duplicate funds or participants within a fund’s bucket, incomplete rosters, invalid identities or amounts, nonconsecutive weeks, and inconsistent previous roots or cumulative totals. The publisher remains responsible for snapshot accuracy, roster completeness against the factory, participant eligibility, and supplying the latest publication artifact.

Only the configured publisher MAY set a root, which MUST take effect immediately. Leaves MUST commit to chain ID, distributor, user, and cumulative entitlement using the documented standard-tree encoding.

Anyone MAY submit a proof. Tokens MUST go to the committed user, for the proven cumulative entitlement less prior claims. Invalid proofs, duplicate claims, and entitlements below prior claims MUST revert. The publisher MUST have no direct withdrawal path for reward principal.

The distributor does not enforce the schedule, bucket split, balance cap, eligibility, or APY. Root publication MUST enforce this policy. The Funds page MUST show the combined weekly rewards budget. Fund APY estimates MUST use the same cap calculation with current prices, show no more than 10,000%, and display capped weekly rewards in the explanation. They MUST explain that published rewards use the publisher’s selected weekly price and MUST NOT present estimates as Merkle entitlements or guarantees.

Deployment and verification

All production dependencies MUST be explicit. Production MUST use official Uniswap V4 deployments. Testnet mirror dependencies MUST match operator-supplied expected bytecode hashes before deployment. Generated ABIs, frontend configuration, tests, and documentation MUST describe only the current architecture. Earlier testnet contracts MUST NOT be treated as compatible.