Bounded ONI emissions. Permanent Sushi liquidity. A new flywheel.

What is Onigiri?

Onigiri is a place to deposit one of three supported assets and earn rewards for participating. You can deposit ETH, ONI, or oniLP. The protocol records your credited deposit, calculates your share of available rewards, and lets you withdraw your credited principal at any time.

The design has two goals at the same time. It gives participants access to a finite pool of ONI rewards, and it uses protocol fees to build assets that stay inside the protocol. Half of protocol working capital permanently removes ONI from circulation. The other half builds permanent SUSHI/WETH liquidity that can earn trading fees.

The two kinds of return

ONI emissions and SUSHI revenue are different. ONI emissions come from ONI that already exists and has been placed in RewardVault. The protocol does not mint more ONI. SUSHI revenue is earned later, when traders use the protocol-owned SUSHI/WETH liquidity and pay trading fees. Keeping these sources separate makes it possible to explain exactly where every reward came from.

How ONI launches into the system

One purpose-built contract calls the official Sushi launchpad and becomes ONI's recorded creator. In the same transaction, it makes the launchpad's maximum $1,000 initial purchase and then an additional 2 ETH purchase. Both purchases execute atomically, with no opportunity for trading between them: they complete together or no launch state is recorded.

The launch transaction writes ONI's name and symbol into the token contract. Its logo, description, website, and social links are Sushi public-profile metadata rather than token supply logic. The authorized launcher wallet signs that profile, and the launcher validates the signature through the standard EIP-1271 contract-signature method so Sushi can verify it came from ONI's recorded creator.

That launch contract remains connected after ONI exists. When the launchpad-owned ONI/WETH position earns trading fees, anyone can press its public poke function. The creator share arrives as ONI and WETH, is converted into ONI and native ETH form, and enters Kitchen's fixed 50/50 routing. The caller cannot choose another recipient or change the split.

What the protocol does not do

Onigiri does not lend user deposits, use leverage, bridge funds to another network, or move principal through a discretionary strategy. Credited ETH stays as ETH, credited ONI stays as ONI, and credited oniLP stays as oniLP. The system's external revenue source is Sushi V3 trading activity.

The 4% protocol portion never has a single destination. Kitchen always divides it equally across both primary routes. Realized creator fees from the ONI/WETH launch position enter the same routing path. The treasury split is separate and applies only after SUSHI/WETH LP trading fees have been realized.

gross vault entry or exit
    |
    +-- 1% developer fee, paid in kind
    +-- 95% credited stake or withdrawal proceeds
    |
    +-- 4% protocol working capital
             |
          KITCHEN
          /     \
       50%       50%
       /           \
ONI buy/direct      SUSHI/WETH protocol-owned liquidity
burn                         |
                             +-- realized V3 trading fees only
                                      |
                                      +-- 50% compound POL
                                      +-- 40% buy and burn ONI
                                      +-- 10% normalize to SUSHI
                                                   |
                                             active ONI stakers

Follow one deposit through the system

Imagine depositing 100 units of a supported vault asset. One unit goes to the fixed developer recipient, four units become protocol working capital, and the remaining 95 units become your credited stake. The same percentages apply when you withdraw, while claiming rewards carries no fee.

The four protocol units then enter Kitchen. Kitchen does not make a judgment call about where they should go. Its rules always divide that working capital into two equal halves: one half supports ONI destruction, and one half supports permanent SUSHI/WETH liquidity.

The canonical oniLP position adds a third, direct source of ONI destruction. Its ONI/WETH principal remains withdrawable by oniLP holders, but its trading fees do not increase the share price. Fee ONI goes straight to the fixed dead address. Fee WETH is kept in a separate queue until a permissionless call uses it to buy ONI for that same address.

Why the second split happens later

Owning liquidity and earning revenue from liquidity are not the same thing. The SUSHI and WETH placed into the position are principal: they are the assets doing the work. Trading fees are the new value earned while that position serves traders. Only those earned fees enter the 50/40/10 flywheel, so the system never has to spend the liquidity principal to create a holder payout.

The $ONI flywheel

A flywheel is a system in which one useful action helps create the conditions for the next one. In Onigiri, staking activity creates protocol working capital. That working capital supports ONI destruction and permanent SUSHI/WETH liquidity. Trading through that liquidity can earn fees, and those fees are routed back into compounding, more ONI destruction, and SUSHI rewards for active ONI stakers.

The loop is rules-based. It does not depend on someone deciding what to buy each week or moving funds into a new strategy. Every stage has a fixed source, a fixed calculation, and a fixed destination.

bounded ONI reward inventory
            |
            v
    ETH / ONI / oniLP staking
            |
            +-- 4% protocol working capital + realized ONI/WETH creator fees
                         |
                      KITCHEN
                      /     \
             50% ONI burn   50% permanent SUSHI/WETH POL
                                      |
                               trading activity
                                      |
                           realized fees only
                              /       |       \
                  50% compound   40% ONI burn   10% SUSHI
                         |                         |
                 deeper permanent POL       active ONI stakers

Bounded rewards begin the motion

Pre-funded ONI rewards give ETH, ONI, and oniLP holders a reason to participate while reward inventory is available. More participation can produce more entry-and-exit activity, and the protocol's 4% portion of those movements becomes working capital. The reward program is bounded because RewardVault holds a finite amount of existing ONI and cannot mint more.

Permanent liquidity carries value forward

Half of Kitchen working capital builds a SUSHI/WETH position that remains owned by the protocol. That capital is not paid out or withdrawn after one cycle. It stays available to serve future trades. Half of the fees later realized from those trades is compounded into the position, allowing earned revenue to add to the permanent liquidity base.

Two routes support permanent ONI destruction

ONI destruction appears in both layers of the flywheel. Kitchen directs 50% of protocol working capital to buying and burning ONI or sending fee-denominated ONI directly to the burn destination. Later, treasury directs 40% of realized SUSHI/WETH trading-fee value to another ONI buy-and-burn route. The sources are different, but both destinations are permanent.

Canonical oniLP trading fees provide another volume-driven burn route. The liquidity principal remains available for normal oniLP redemption, while the fees produced when traders use that ONI/WETH position continually remove ONI directly or buy ONI with collected WETH. This can offset part of the circulation pressure created when pre-funded rewards move into users' hands, although its effect depends on real trading volume and cannot guarantee a token price.

SUSHI revenue connects the loop to ONI staking

The remaining 10% of realized trading-fee value is normalized into SUSHI and sent to active ONI stakers. This gives the ONI vault a reward stream tied to actual Sushi market usage, separate from its bounded ONI emission stream. If no ONI is staked, the SUSHI waits in a queue until it can be distributed safely.

The flywheel can outlive emissions

New ONI emissions end when the unreserved RewardVault inventory is exhausted. The permanent-liquidity side does not depend on minting another reward token. Existing POL can continue serving trades, realized fees can continue compounding and burning ONI, and the SUSHI holder allocation can continue flowing to active ONI stake.

Capital and revenue provenance

Think of separate labeled envelopes

The contracts treat each kind of balance as though it lives in a clearly labeled envelope. An envelope for user deposits cannot be opened by Kitchen. An envelope for promised rewards cannot be used by another pool. An envelope for protocol-owned liquidity cannot be mistaken for trading revenue. The tokens may exist in connected contracts, but their accounting purpose remains explicit.

Principal means the asset base that belongs to a user or keeps a liquidity position operating. Working capital means protocol-owned value routed by Kitchen, including the 4% farm portion and realized ONI/WETH creator fees. Revenue means value newly earned as trading fees. These words describe different sources and therefore different permitted destinations.

Why source tracking matters

A token balance alone cannot explain who owns it or what it may be used for. Onigiri records both the amount and its source. This provenance is what prevents a convenient-looking balance from being reused for an unrelated purpose. It is also what makes the protocol's core solvency rules possible to check onchain.

Three staking vaults

Each pool has an independent immutable Emax and K curve. Reward claims carry no 5% fee, and credited principal remains withdrawable at any time.

Choosing a vault

Depositing, earning, and leaving

A deposit first checkpoints rewards so the time before your arrival belongs to the people who were already staked. Your fee is then separated and only the remainder becomes credited principal. While you remain staked, later checkpoints add your share of new rewards to the pool's accounting. When you claim, rewards are paid without a claim fee. When you withdraw, the vault applies the exit fee and returns the remaining asset to you.

Each vault displays a live rate. The pool's total emission rate responds continuously to the amount staked, while each participant receives the share represented by their position in that pool.

What happens when you use Onigiri

The interface presents each action simply, while the contracts follow a precise order underneath. That order protects earlier participants, separates fees from deposits, and backs every reward before it appears as claimable.

When you stake ETH

The ETH vault first updates reward accounting through the current block. It sends 1% of the incoming ETH to the fixed developer recipient and records 4% for Kitchen. The remaining 95% becomes your credited ETH principal. That credited ETH is not wrapped, traded, lent, or supplied elsewhere. Your vault balance begins earning its share of the ETH pool's ONI emissions from that point forward.

When you stake ONI

The ONI vault follows the same fee pattern in ONI. Your credited ONI earns from the ONI pool's finite emission budget and receives its share of SUSHI whenever the protocol-owned SUSHI/WETH position realizes fees and treasury sends the holder portion into the vault. The ONI reward balance, SUSHI reward balance, and ONI principal balance remain three distinct obligations.

When you stake oniLP

You deposit fungible shares rather than a Sushi position NFT. The LP vault separates the fee shares before it credits your principal. The developer receives the 1% share portion. Only the protocol's 4% share portion may be redeemed into ONI and ETH for Kitchen. Your credited oniLP shares stay inside the LP vault and cannot be included in that redemption.

When you claim rewards

A claim first brings the pool's accounting current. The vault calculates what its global reward index owes your stake, subtracts anything already recorded as paid, and requests exactly that amount from the pool's reserved reward balance. ONI and SUSHI reward claims do not pass through the entry-and-exit fee split.

When you withdraw

The vault checkpoints before changing your stake, applies the fixed exit fee to the amount being withdrawn, and returns the remainder. Any rewards already earned remain claimable according to their own ledgers. Withdrawals and reward claims remain available at all times.

OniEthLiquidityVault wraps one canonical ONI/WETH V3 position into transferable 18-decimal shares. An oniLP share is a claim on liquidity principal, not on the trading fees produced by that liquidity. Before every share issuance or redemption, the vault checkpoints Sushi V3 fee growth and moves those fees into their own protocol-directed path.

principal NAV before mint =
    TWAP value of idle principal ONI
  + idle principal WETH
  + TWAP value of active position principal
  - queued protocol fee WETH

new shares =
    contribution TWAP value * existing supply
    / principal NAV before mint

Crystallizing first makes the boundary exact. A new depositor cannot receive old fees, an exiting holder cannot withdraw the protocol fee queue, and neither person is priced against a balance that serves two owners. Redemption assigns pro-rata principal reserves, burns pro-rata position liquidity, and adds all principal from that burn without a second pro-rata reduction.

What an oniLP share represents

A Sushi V3 liquidity position has two principal assets and may also have trading fees waiting to be collected. OniEthLiquidityVault makes the principal divisible through oniLP. Owning 1% of all oniLP shares means owning 1% of the vault's withdrawable ONI/WETH principal, including idle principal and the assets currently active in the canonical position.

NAV means net asset value. The vault translates principal ONI and WETH into one common WETH value so deposits and redemptions can be compared fairly. The separately recorded pendingWethFees balance is deliberately subtracted because it already belongs to the buyback route.

How to create, use, and redeem oniLP

To create oniLP, enter both ONI and native ETH in the liquidity panel and approve ONI when prompted on first use. Deployment initializes the vault once with a minimum-value seed and permanently locks minimum liquidity at the fixed dead address. Later, the app previews your shares and submits a protected minimum. The vault checks the live pool against its TWAP limit, adds the usable pair to the canonical ONI/WETH position, keeps any unmatched remainder as idle principal, and issues shares from the complete value you supplied. Redemption similarly previews and protects separate minimum ONI and ETH outputs.

After creation, oniLP can remain in your wallet, move to another wallet, be redeemed for its proportional ONI and native ETH principal, or be staked in the LP Vault for bounded ONI emissions. Creating and redeeming oniLP do not apply the farm's 5% charge. The charge applies when oniLP enters or exits the staking vault: 1% goes to the developer route, 4% goes through Kitchen, and 95% becomes the credited stake or withdrawal proceeds.

Redemption operates independently from buybacks. The vault first separates newly earned V3 fees, then burns the requested share of position liquidity and returns the holder's proportional principal. The fee-WETH queue never delays a withdrawal.

Protocol-directed liquidity, with withdrawable principal

Depositing oniLP into the farm changes custody, not ownership of principal. Credited oniLP remains withdrawable user property. That means the capital itself is not strict protocol-owned liquidity. It is better described as protocol-directed liquidity: participants keep their capital claim, while the trading-fee yield generated by the shared position follows a route fixed for the benefit of ONI.

The rule applies to the complete canonical position, whether an oniLP share is in a wallet or staked in the farm. There is no mixed class of fee-earning and non-fee-earning shares, and moving a share immediately before collection cannot change who owns a fee. oniLP stakers earn bounded ONI emissions; the V3 trading fees support ONI destruction instead of becoming extra oniLP value.

This makes oniLP the protocol's market-powering vault. Users supply withdrawable ONI/WETH principal, every active position produces a protocol-directed fee stream, and that stream supports ONI destruction whenever trading volume exists. The elevated emission curve is the compensation layer: it is intentionally the highest because oniLP holders take two-asset price exposure, impermanent loss, and no claim on the position's trading fees.

How oniLP trading fees become ONI destruction

Collected fee ONI is transferred directly to 0x000000000000000000000000000000000000dEaD. Collected fee WETH remains wrapped and fully backed inside the vault, but in a dedicated queue excluded from every user's NAV and redemption. Any account may call pokeFees(). The vault unwraps only a bounded queue amount and asks the immutable OniBuyback route to purchase ONI directly for the same dead address.

Buyback execution is fully separate from deposits and redemptions. A pokeFees() call proceeds only when its TWAP, slippage, trade-size, and routing checks pass; otherwise, the WETH stays economically unchanged in its backed queue for a later call. oniLP creation and redemption remain available throughout.

The separate 4% LP farm route

The LP farm's entry-and-exit fee is independent from ongoing V3 trading fees. It isolates the exact 1% developer shares, exact 4% protocol shares, and credited user shares before doing anything else. Only the 4% protocol shares are redeemed into ONI and ETH for Kitchen's 50/50 route. No credited oniLP share enters that redemption.

Why fees are collected before shares change

Suppose ten people supplied liquidity yesterday and the position earned fees overnight. Those fees remain assigned to the liquidity that earned them. Before minting new shares, the vault makes the pool account for every fee earned so far, removes those fees from principal accounting, and prices the newcomer only against the principal they are joining.

The same rule applies on the way out. Before shares are retired, the vault separates fees, calculates the exiting holder's principal proportion, removes the matching amount of position liquidity, and pays the corresponding ONI and native ETH. The protocol fee queue remains backed and the remaining holders keep their proportion of the principal left behind.

Why TWAP is used for value

TWAP means time-weighted average price. Instead of trusting a single instant that may contain a brief price spike, the vault uses an average observed through the canonical pool over a fixed window. This gives share calculations a steadier reference and makes a momentary trade less able to distort how many shares a deposit receives.

Finite rewards become irrevocable at checkpoint

RewardVault contains existing ONI; it cannot mint. FarmController calculates all three pools from one global interval and one pre-change stake snapshot.

rate_i = Emax_i * stake_i / (stake_i + K_i)

available = tracked RewardVault inventory
            - total rewards already reserved

if total scheduled > available:
    budget_i = scheduled_i * available / total scheduled

1. 01
   Checkpoint together

   All pool schedules use the same timestamp and pre-change stake.

2. 02
   Fit the new interval to inventory

   When scheduled rewards exceed available inventory, all three new budgets scale proportionally.

3. 03
   Reserve atomically

   Every represented reward is added to that pool's reserve in the same transaction as its reward index.

4. 04
   Claim from one reserve

   A vault can debit only its own pool. Published reward indexes stay fully funded and unchanged.

Funding rewards can be as simple as sending ONI

Any ONI holder can transfer tokens straight to the RewardVault address. Because a normal token transfer cannot notify the receiving contract, the amount first appears as waiting inventory. At the next protocol checkpoint, FarmController settles the earlier interval using only the inventory that was already active, then recognizes the newly arrived ONI for future rewards. At launch, the start transaction performs this synchronization itself.

The explicit donate route remains available for wallets and integrations that want the transfer, checkpoint, accounting update, and donor event bundled into one transaction. Both routes add real ONI to the same bounded reward inventory; neither can rewrite rewards from an earlier interval.

How the reward curve feels in practice

Emax is the highest total emission speed a pool can approach. K describes how much stake is needed for that pool to reach half of that speed. When a pool is small, adding stake raises its total reward flow meaningfully. As the pool grows, total emissions keep rising but approach the ceiling more slowly. Because more stake is also sharing those rewards, the reward rate per deposited unit falls as participation grows.

Each vault has its own curve. Activity in the ETH pool does not directly rewrite the ONI or LP curve. The pools meet only when the controller checks whether the shared finite RewardVault inventory can cover the next interval for all three.

The launch calibration places oniLP clearly above the other farms. At each pool's intended saturation point, the modeled oniLP ONI APR is twice the ONI farm's ONI APR. Live APRs still move with token prices, principal value, and participation, but the larger oniLP ceiling is deliberate compensation for impermanent-loss exposure and the trading fees surrendered to ONI buybacks.

How to read the runway

Runway estimates how long the ONI that has not already been reserved can continue funding new rewards. The live estimate uses the emission speed created by today's stake. The maximum-rate estimate assumes all three pools run at their absolute ceilings every second, making it the more conservative forecast. The interface shows both because participation can change the live number without changing the vault's inventory.

Runway is a live estimate rather than a fixed date. More ONI sent to RewardVault extends it, while higher aggregate emissions use inventory faster. Rewards already assigned by a checkpoint are excluded from the available balance and remain fully reserved for the users who earned them.

A checkpoint turns time into a funded promise

Rewards build up over time, but the accounting is advanced at checkpoints. A checkpoint measures the elapsed interval, calculates all three pool budgets from the stake that existed during that interval, and reserves the required ONI at the same moment it raises the reward indexes. Once an index says a reward has accrued, matching ONI has already been spoken for.

This is why every published reward remains intact. When available inventory covers only part of a new interval, the controller funds that interval proportionally across all three pools and leaves every earlier checkpoint unchanged.

After current ONI inventory is fully allocated

Every ONI reward assigned by an earlier checkpoint remains reserved and claimable. Credited principal remains withdrawable, and realized-SUSHI revenue, Kitchen routing, and treasury operations continue independently.

LP fees are isolated before redemption

Every entry and exit computes the 1% developer balance, 4% protocol balance, and user remainder independently. In the LP farm, those are share balances—not estimates of underlying assets.

gross oniLP shares
    |
    +-- 1% developer shares --> immutable developer recipient
    +-- 4% protocol shares  --> redeem to ONI + ETH --> Kitchen
    +-- remainder           --> credited principal or user payout

The contract checks physical oniLP solvency before the developer transfer, before the protocol redemption, after the protocol redemption, and before completing a withdrawal. Only the isolated protocol shares can become Kitchen working capital.

A simple 100-unit example

If 100 units enter a farm, 1 unit is the developer portion, 4 units are the protocol portion, and 95 units become credited stake, subject to the contract's downward rounding at token precision. The fee is paid in the asset used by that vault: ETH for the ETH vault, ONI for the ONI vault, and oniLP shares for the LP vault.

The exit is a separate event with the same percentages. If a user asks to withdraw 100 credited units, 1% of that withdrawal goes to the developer recipient, 4% becomes protocol working capital, and the user receives the remainder. A reward claim is different: the full claimable reward is paid with no 5% deduction.

Why LP fee shares are separated first

An oniLP share owns a fraction of an underlying ONI/WETH position. The LP farm therefore cannot safely estimate the 4% fee in ONI and ETH while those shares are mixed with user balances. It first marks the exact developer shares, protocol shares, and user shares as separate amounts. Only then may the protocol shares be redeemed. This ordering proves that the redemption came from protocol-owned fee value rather than credited user shares.

Kitchen accepts isolated protocol-owned ONI/ETH farm fees, realized creator fees from the launchpad-owned ONI/WETH position, and explicit donations. It does not receive or allocate credited principal, and SUSHI/WETH trading fees remain in the separate treasury revenue path.

Anyone may donate native ETH, ONI, or both from the Kitchen panel. An ONI donation requires the donor's wallet to approve Kitchen first; the interface handles that approval before submitting the deposit. ETH and ONI are recorded in separate pending balances, then follow the same fixed 50% ONI-destruction and 50% SUSHI/WETH-liquidity route when processing becomes eligible.

oniBurnBps = 5_000
sushiFlywheelBps = 5_000
oniBurnBps + sushiFlywheelBps = 10_000

The constructor rejects any other weights. Processing is permissionless, thresholded, cooled down, batch-limited, and atomic across each selected asset route.

What Kitchen actually does

Kitchen is an automatic router, not an investment manager. It receives only protocol-owned ONI and ETH, keeps a running balance for each asset, and processes eligible amounts through routes fixed at deployment. No caller decides the split, substitutes another token, or sends the output to a personal address.

The threshold and cooldown combine small balances into efficient trades, while batch limits keep each maintenance call bounded. Amounts below the quote threshold stay safely pending and join a later batch.

The ONI destruction half

When this half begins as ETH, the protocol buys ONI through the approved ONI/WETH route and sends the result to the canonical dead address. When it already begins as ONI, it goes directly to the same address. The address is fixed in contract code as 0x000000000000000000000000000000000000dEaD; deployment cannot substitute another recipient, and no ONI burn() function is called.

The SUSHI/WETH liquidity half

This half is normalized into ETH and handed to the treasury liquidity path. The treasury buys the matching SUSHI needed for a two-sided position and adds both assets to permanent protocol-owned liquidity. The position serves SUSHI/WETH traders and earns fees when they swap.

The liquidity adapter permanently owns a direct SUSHI/WETH V3 position. Its compile-time width is exactly 120,000 ticks—roughly 162,750× from boundary to boundary—and is tick-aligned. Its center is derived from the arithmetic-mean TWAP; permissionless callers never provide ticks.

center = floorToTickSpacing(arithmeticMeanTwapTick)
lower  = center - 60,000 ticks
upper  = center + 60,000 ticks

eligible for recenter when:
    twapTick < lower || twapTick >= upper

1. 01
   Validate price

   Spot must remain within the immutable deviation ceiling around TWAP.

2. 02
   Crystallize fees first

   Old-position SUSHI and WETH fees enter fee-only reserves.

3. 03
   Isolate principal

   The full old position burns into separate principal reserves.

4. 04
   Derive and rebalance

   Only principal uses bounded typed SUSHI/WETH swaps; no arbitrary route exists.

5. 05
   Remint

   Principal enters the sole TWAP-derived range; residual principal stays explicitly reserved.

recenter() is parameterless. It cannot change width, pool, tokens, fee tier, TWAP window, slippage, recipient, or allocation. There is no external POL removal or sweep function.

What protocol-owned liquidity means

POL stands for protocol-owned liquidity. The protocol, rather than an individual depositor, owns the SUSHI and WETH placed in this position. That liquidity is designed to stay in the system permanently. It gives traders a pool in which to exchange SUSHI and WETH and earns fees for the protocol's revenue flywheel whenever they trade.

Why a V3 position has a range

The position remains permanently owned and fully accounted for at every market price. While the price is inside its chosen Sushi V3 range, it serves both sides of trades and earns fees. When price moves outside that range, recentering places the assets into a new range around the longer-term observed price.

Onigiri uses a deliberately wide, fixed-width range. Wide coverage reduces how often maintenance is needed, while the TWAP-derived center gives the next position an objective reference. The range can move when the market genuinely moves, but its width and method of calculation do not change.

Why the caller cannot choose the new range

Anyone may pay the gas to call an eligible recenter, which helps the position remain maintainable without depending on one operator. The caller is only starting a predefined procedure. The contracts calculate the ticks, verify the observed prices, separate fees from principal, rebalance through approved routes, and return principal to the newly derived position.

Holder SUSHI comes only from realized LP fees

The adapter tracks pendingFeeSushi/pendingFeeWeth separately from principalSushiReserve/principalWethReserve. Collection can transfer only the fee ledger to SushiTreasuryVault.

1. snapshot treasury SUSHI and ETH balances
2. crystallize and collect adapter fee reserves
3. require reported amounts == exact balance deltas
4. convert collected SUSHI fees to ETH
5. combine with collected WETH fee value
6. allocate fee-only normalized value:
       50% compound POL
       40% buy and burn ONI
       10% buy SUSHI for active ONI stakers

The 10% leg therefore includes the WETH component of V3 fees: it is normalized to the common ETH value and converted into SUSHI before transfer. OniFarmVault advances accSushiRewardPerShare only after the bound treasury has transferred the corresponding SUSHI into the farm. Carried treasury liquidity and POL principal never enter this calculation.

What “realized fees” means

A liquidity position can contain principal, fees that have accumulated in the pool, and unused assets waiting for a future liquidity addition. Onigiri calls revenue realized only after the adapter crystallizes the position's earned fees and the treasury verifies the exact SUSHI and WETH amounts it actually received. A reported estimate or a pre-existing treasury balance is not enough.

Why both fee assets are normalized

Sushi V3 pays fees in both assets of the pair. If the flywheel divided only the SUSHI side, the WETH side would not contribute proportionally. The treasury therefore translates both collected fee components into one common ETH value before applying 50/40/10. This makes each destination receive its intended share of the complete fee event.

After the split, the compound portion returns to protocol-owned liquidity. The burn portion buys ONI and destroys it. The holder portion buys SUSHI and transfers that SUSHI into OniFarmVault. Only after the tokens arrive does the ONI farm increase its SUSHI-per-share index.

How queued SUSHI enters the ONI vault

The holder allocation enters a fully backed ONI-farm queue. Once qualifying ONI stake exists, queued SUSHI streams prospectively over seven days. The immutable minimum position and prospective stream ensure each participant earns only from their active staking period.

Permissionless, bounded automation

Every account can checkpoint emissions, collect and route realized ONI/WETH creator fees, crystallize and process canonical oniLP trading fees, process eligible Kitchen batches, harvest realized SUSHI/WETH fees, distribute queued SUSHI when stake exists, or recenter out-of-range POL. Permissionless means execution access, not parameter control.

Permissionless does not mean uncontrolled

A permissionless function is a public maintenance button. Any account can press it, so the protocol does not have to wait for a special keeper. The button's result is still determined entirely by contract rules. The caller cannot choose a friendlier price, invent a route, change a recipient, widen a range, or include a different balance.

Bounded means the work has limits. Price checks compare the immediate market with the time-weighted reference. Slippage rules set a minimum acceptable output. Maximum trade sizes and chunk counts cap how much can happen in one call. Thresholds and cooldowns prevent needless repeated processing of tiny balances.

Routine maintenance available to anyone

• Bring all three ONI reward pools to the current checkpoint.
• Collect launch-position creator fees and route them into Kitchen.
• Turn oniLP fee WETH into ONI sent to the fixed dead address.
• Process an eligible batch of Kitchen working capital.
• Crystallize and harvest realized SUSHI/WETH trading fees.
• Distribute queued SUSHI when active ONI stake exists.
• Recenter POL when TWAP has moved outside the active range.
• Carry ineligible or undersized work forward safely for later processing.

Contract architecture

One identity across every module

Every production contract identifies itself on-chain as part of Onigiri Finance. Anyone can call onigiriContractInfo() to read the protocol name, the contract's unique module label, the canonical oni.finance website, and the official @oni_finance profile directly from the deployed code.

Deployment produces an OnigiriContractBranded event, and protocol-specific activity uses clear names such as OnigiriFlywheelProcessed, OnigiriCreatorFeesRouted, and OnigiriPOLRangeRecentered. Wallet standards and required Sushi callback names stay unchanged, so the branding does not interfere with compatibility.

The launch boundary

OnigiriLaunchDeployer is intentionally narrow. Before launch, its owner can fund or refund launch ETH. Its launch call checks the official launchpad, factory, router, WETH, oracle price, pool, creator identity, deadline, and both minimum outputs. It then performs the maximum launch purchase and fixed 2 ETH purchase atomically. After launch, it cannot launch again, replace ONI, choose another pool, or redirect the launch position.

Once the matching Kitchen is bound, the connection is permanent. The contract has no creator-fee withdrawal function. Its public maintenance call realizes whatever creator share Sushi Launchpad has assigned, routes all received ONI and WETH into Kitchen, and attempts processing when the threshold and cooldown allow it.

A guided tour through the contracts

The farm vaults are the user-facing custody layer. They accept the supported staking assets, keep credited principal backed, and calculate each account's rewards. They do not decide how much ONI the whole system may emit; FarmController does that for all three pools together.

FarmController turns elapsed time and live stake into pool reward budgets. RewardVault is the finite store of existing ONI that backs those budgets. The controller may reserve and release rewards through authenticated pool paths, while RewardVault itself cannot mint ONI.

Fee assets travel through a different side of the architecture. Kitchen handles the primary 50/50 working-capital split. The swap and buyback adapters restrict which markets may be used. The Sushi liquidity adapter holds permanent POL and distinguishes its principal from its earned fees. SushiTreasuryVault verifies those fees and applies the secondary 50/40/10 revenue split.

OniEthLiquidityVault and LpFarmVault have related but different jobs. The first turns canonical ONI/WETH principal into fairly priced fungible oniLP shares and isolates the position's protocol-directed trading fees. The second lets those shares participate in the finite ONI reward program while keeping credited user shares separate from the farm's 1% developer and 4% protocol shares.

On-chain identity

Every Onigiri contract carries the same small identity record in its deployed code. Think of it as a permanent digital business card. Any wallet, block explorer, indexer, or user can read that record directly from the contract instead of relying on a copied label or unofficial link.

The identity record answers two separate questions. The shared brand identifier answers, “Is this presenting itself as part of Onigiri Finance?” The module identifier answers, “Which exact job is this contract built to perform?” Reading both is important because each production module has a different responsibility.

What the identity function returns

The production module map

Module identifiers are deliberately plain. They make logs, integrations, and deployment checks easier to read without requiring someone to infer a contract's purpose from its address.

How branded events help

Each module emits OnigiriContractBranded when it is deployed. The event records the shared brand, the module identifier, the protocol name, and the official links in one place. This gives explorers and data tools a consistent first record for classifying the deployment.

Protocol activity follows the same naming pattern. Events such as OnigiriCreatorFeesRouted, OnigiriFlywheelProcessed, and OnigiriPOLRangeRecentered state both the protocol and the action. That makes a transaction history easier to understand: a reader can distinguish a launch-fee route, a completed economic cycle, and a liquidity-range move without decoding anonymous-looking logs.

Why a few names stay standard

Branding never replaces an ecosystem standard. oniLP keeps the standard ERC-20 Transfer and Approval events so wallets and portfolio tools can recognize it normally. Required Sushi V3 callbacks and the EIP-1271 isValidSignature method also remain exact because external systems rely on those names. Custom Onigiri names are used everywhere they improve clarity without breaking compatibility.

Core accounting invariants

RewardVault.totalReleased <= RewardVault.totalFunded
totalReservedRewards <= RewardVault.remainingInventory
pool claim debits only that pool's reservedRewards

ETH farm balance   >= credited ETH
ONI farm balance   >= credited ONI
LP farm oniLP      >= credited oniLP
ONI farm SUSHI     >= indexed + queued SUSHI liability

  entry / exit = 1% developer + 4% protocol + remainder
Kitchen       = 50% ONI destruction + 50% SUSHI/WETH POL
fee revenue   = 50% compound + 40% ONI burn + 10% SUSHI

POL fee reserves and principal reserves are separately backed
oniLP supply changes occur only after V3 fee crystallization
oniLP pending fee WETH <= vault WETH and is excluded from principal NAV

How to read an invariant

An invariant is a rule that must remain true before and after every successful transaction. The symbol >= means “is at least.” For example, “ETH farm balance is at least credited ETH” says the vault must physically hold enough ETH to cover all ETH it records as user principal.

The reward invariants say that the system cannot release more ONI than it was funded with, and one pool cannot spend another pool's reservation. The fee invariants say every entry and exit can be reconstructed as developer fee, protocol fee, and user remainder. The liquidity invariants say principal and revenue remain separately backed even when the position is collected or recentered.

These are not target percentages that may drift over time. They are accounting boundaries the contracts enforce while processing deposits, withdrawals, claims, routing, liquidity maintenance, and fee harvests.

Immutable protocol parameters

What immutable means here

An immutable parameter is fixed when its contract is deployed and has no later setter. The entry and exit fees, routing weights, pool curve settings, price-check windows, execution bounds, canonical assets, and relevant market identities cannot be changed after deployment.

The contracts are non-upgradeable, so their implementation cannot be replaced through a proxy. ONI is created by the official Sushi launchpad through the dedicated launch contract, and the protocol has no ONI minting, supply-management, blacklist, or token-fee authority.

Some system state naturally changes without changing the rules. Stake totals move as users enter and leave. Reward inventory falls as rewards accrue and are claimed. A POL range may recenter when the immutable formula says it is out of range. Those are expected outcomes of fixed rules acting on new conditions.

Glossary

These terms appear throughout the protocol because they describe different kinds of value and different stages of accounting. The distinctions matter, but the ideas are straightforward once each word has a stable meaning.

Common questions

Can Onigiri mint additional ONI?

No. Sushi Launchpad creates the fixed ONI supply once, and Onigiri has no authority to mint more. Farming rewards are existing ONI transferred into RewardVault and accepted into its tracked inventory.

How does ONI launch become the protocol's reward supply?

ONI is created through the Sushi launchpad with its fixed supply and ONI/WETH market already established. The launch purchase and immediate 2 ETH purchase send ONI to the authorized deployment signer. The deployment runner measures the ONI actually received and sends the configured percentage directly to RewardVault before emissions are initialized.

How are ONI's logo and description added?

The launch call creates the token with its on-chain name and symbol. The logo, description, website, and social links are then saved as Sushi profile metadata. The launcher's authorized wallet signs the metadata update, while the launcher confirms that signature through EIP-1271 as ONI's recorded creator.

How do ONI/WETH launch fees reach the flywheel?

The launch contract remains the launchpad's recorded creator. Anyone can call poke to realize the creator share of ONI/WETH trading fees and send its ONI and WETH value into Kitchen. Kitchen then applies the same fixed 50% ONI-destruction and 50% SUSHI/WETH-liquidity routing used for other working capital.

Can anyone add more ONI rewards?

Yes. Anyone may send ONI directly to RewardVault. The next controller checkpoint recognizes it for future emissions after safely closing the preceding interval. Integrations may instead call donate when they want immediate accounting and an attributable donation event.

Where does the yield come from?

There are two user reward sources. Finite ONI emissions come from the pre-funded RewardVault inventory. SUSHI paid to active ONI stakers comes only from realized trading fees earned by permanent SUSHI/WETH liquidity. Separately, trading fees earned by the oniLP ONI/WETH position buy and destroy ONI rather than becoming a user payout.

Can user deposits be sent through Kitchen?

No. Kitchen accepts the isolated 4% protocol portion, realized ONI/WETH creator fees, assets redeemed from protocol-owned oniLP fee shares, and explicit donations. Credited user principal is not protocol working capital.

Are reward claims charged the 5% fee?

No. The 1% developer and 4% protocol split applies to farm entry and exit. ONI and SUSHI reward claims are paid without that fee.

What happens after current ONI inventory is fully allocated?

ONI reserved by earlier checkpoints remains claimable, credited principal remains withdrawable, and fee-driven Kitchen and SUSHI revenue operations continue. Additional ONI transferred into RewardVault can fund future emission intervals.

Why can the displayed reward rate change?

Each pool uses a smooth curve based on its current total stake. More participation raises the pool's total emission rate toward its fixed ceiling while distributing those rewards across more stake. The displayed rate updates continuously to reflect those live conditions.

Why do only ONI stakers receive SUSHI?

The realized-fee flywheel assigns its 10% holder portion specifically to active ONI stake. ETH and oniLP stakers receive finite ONI emissions but do not share that SUSHI index.

How is SUSHI handled before qualifying ONI stake exists?

SUSHI remains fully backed in the ONI farm. Once qualifying ONI stake exists, it streams prospectively into the reward index over seven days, assigning rewards only to active staking time.

Is oniLP the same as a Sushi V3 NFT?

No. OniEthLiquidityVault manages the canonical concentrated-liquidity position and issues divisible ERC-20-style oniLP shares over its principal value. Users can transfer or stake those fungible shares without handling the underlying position directly.

Who owns oniLP principal?

oniLP holders retain the principal claim. The position is protocol-directed liquidity: holders keep withdrawable principal, while all trading fees from the canonical position follow immutable ONI-destruction routes. The farm's separate 4% protocol share fee is redeemed into Kitchen without touching credited shares.

Can a maintenance caller choose a different pool or price range?

No. Permissionless callers decide only whether to start eligible work. Assets, pools, routes, fee tiers, price windows, range width, range formula, execution bounds, and recipients are fixed by the deployed contracts.

Can protocol-owned SUSHI/WETH liquidity be withdrawn?

No external removal or sweep path exists. Recentring may remove assets from an old range only as part of placing the separately accounted principal into the next deterministic range.

How can I recognize an Onigiri contract?

Read onigiriContractInfo() from the contract. It returns the shared Onigiri brand identifier, that contract's module identifier, the Onigiri Finance name, and the official website and X profile. Compare the module identifier with the on-chain identity map above and the address with the canonical deployment record before interacting.