A project’s budget is a model of its future. Every line item in that model is either a fixed value or a variable — a known cost or an estimate subject to revision. The distinction matters because variable costs require contingency reserves, introduce forecast error, and in cases where the variable is correlated with the project’s own success, create a counterintuitive dynamic where growing protocols pay more for the same service.
Infrastructure costs should be fixed. When they are not, the consequences accumulate in ways that are easy to underestimate at the budgeting stage and expensive to absorb at the execution stage.
This article addresses the operational and financial mechanics of that distinction — specifically in the context of liquidity locking and token vesting infrastructure, where percentage-based and flat-fee models produce materially different outcomes depending on the protocol’s scale.
The Anatomy of a DeFi Project Budget
A protocol preparing for launch allocates capital across several categories: development, security audits, legal and compliance, marketing, and operational runway. Each of these categories has a cost structure — some are billed at fixed rates, some are time-and-materials, and some are contingent on outcomes.
Infrastructure costs — the fees paid to on-chain service providers for locking, vesting, and settlement — are typically treated as a minor line item. At early stages, with small pool sizes and limited allocations, this treatment is defensible. The fees are small enough in absolute terms that their variability does not materially affect the budget model.
The problem emerges at scale. A project that budgets infrastructure costs at the $50,000 pool stage and then raises additional capital, grows its liquidity, or expands to multiple chains will encounter a cost structure that was never modeled because the variable was never identified as a risk.
At $1,000,000 in liquidity, a 1% locking fee is $10,000. At $5,000,000, it is $50,000. Neither figure was in the budget prepared at launch. Both figures represent real capital extracted from the project’s treasury or liquidity position at the moment of locking — capital that could otherwise have been allocated to development, security, or runway extension.
Percentage Fees as an Unmodeled Variable
In standard financial modeling, costs are classified as fixed or variable, with variable costs typically tied to output volume — units produced, transactions processed, users served. The cost driver is the project’s activity.
Percentage-based locking fees introduce a cost driver that is neither output volume nor activity. It is pool value. And pool value is correlated with investment inflows — which means the fee grows precisely when the project is succeeding.
This correlation has a specific financial property: it behaves like a success tax. The more capital a project attracts, the more it pays to lock that capital. The infrastructure cost is not fixed at a level reflecting the service’s operational complexity — it scales with the project’s fundraising performance.
A project that raises $200,000 in a seed round and locks its liquidity pays $2,000 at 1%. The same project that successfully raises a second round, grows its pool to $2,000,000, and attempts to lock its updated liquidity position pays $20,000 — for the same service, the same contract call, the same lock duration.
No other infrastructure category operates this way. Cloud compute charges per request or per compute unit. Audit firms charge per engagement scope. Legal counsel charges per hour. None of these providers increase their fee because the project attracted more investors. The percentage-fee locker is unique in tying its revenue directly to the project’s capital formation success.
From a budget modeling standpoint, this means every subsequent capital raise requires a reassessment of the infrastructure cost line — not because the service has changed, but because the basis for the fee has changed. The variable is external to the project’s operational decisions and tied to market conditions outside its control.
The Multi-Chain Multiplier
Modern protocol deployment is not a single-chain operation. Base, Arbitrum, and Optimism each serve distinct user populations with different liquidity profiles and ecosystem dynamics. A protocol with genuine cross-chain ambitions deploys liquidity pools on each chain and locks each pool independently.
Under a flat-fee model, the cost of this expansion is linear and fully predictable. Three chains, three locks, three flat fees. The budget line is fixed before deployment begins, and the total cost is the same whether each pool holds $50,000 or $5,000,000.
Under a percentage model, the cost of multi-chain expansion is a function of the total capital deployed across all chains — a figure that is unknown at budget time and may change materially between budget preparation and deployment execution. A pool sized at $500,000 per chain at the time of budgeting might be $1,500,000 by the time the locks are created. The infrastructure cost triples. The service rendered does not.
This creates a practical planning problem. The team preparing the budget for a multi-chain expansion cannot produce a defensible infrastructure cost estimate under a percentage model without also producing a capital raise estimate with low uncertainty — two forecasts that are difficult to produce independently and nearly impossible to produce jointly with useful precision.
Under a flat model, the budget line is trivial to calculate and permanently stable once calculated. Multiply the number of locks by the flat fee per lock. The total is the total. It does not change.
Treasury Allocation Precision
Protocol treasuries operate under allocation constraints. Capital committed to infrastructure cannot be committed to development, security, or community incentives. In a well-managed treasury, every allocation is a tradeoff with an opportunity cost.
Percentage-based fees introduce a compounding allocation uncertainty across the treasury’s planning horizon. Every lock event — at launch, at each liquidity expansion, at each chain addition — requires a new infrastructure allocation of unknown size. The treasury cannot pre-allocate reserves for these events with precision because the fee is not known until the pool value is known, which is not known until the capital is raised, which is not known until the round closes.
This uncertainty is not catastrophic in isolation. But it compounds with other variables in the treasury model — market conditions, development timelines, audit costs — to produce a budget with wider uncertainty bands than a flat-fee infrastructure stack would generate.
A treasury operating with flat-fee infrastructure can calculate, at budget time, the total infrastructure spend for the protocol’s first two years of operations with high precision: the number of planned lock events, multiplied by the fixed cost per event, produces a deterministic total. That total does not change because a pool grew faster than projected. It does not change because a second chain was added to the deployment plan. It is a fixed line in the budget.
This precision has operational value that is easy to overlook because it manifests as the absence of a problem rather than the presence of a benefit. The team does not face an unexpected infrastructure cost at a critical capital moment because there are no unexpected infrastructure costs.
The Lock Extension Case
Liquidity lock durations are extendable. A project that locks for 365 days may later determine that extending to 730 days strengthens its commitment signal to a new investor class or aligns better with a revised development timeline. The extension event is an additional infrastructure interaction — and under a percentage model, it is an additional extraction event.
UNCX, for example, applies its 1% LP fee at the point of relocking — not just at initial lock creation. A project extending a $1,000,000 liquidity lock pays $10,000 at the time of extension, in addition to the $10,000 paid at initial creation. Two lock events on the same pool at the same percentage rate cost $20,000 before the lock has ever expired.
Under a flat model, the extension cost is bounded by the flat fee structure. If extensions are free — as they are in 0xKeep’s architecture — the decision to extend carries no incremental infrastructure cost. The team can extend the lock duration whenever it is strategically appropriate without running a cost calculation first.
The behavioral consequence of this difference is worth noting. Projects operating under percentage-fee infrastructure face a financial disincentive to extend locks — a $10,000 cost at $1M pool size is not trivial. Projects operating under flat-fee infrastructure face no such disincentive. The decision to strengthen the commitment signal to investors is not complicated by an infrastructure cost calculation.
Budgeting for Scale: A Worked Example
Consider a protocol with the following operational plan over 24 months:
- Month 1: Launch on Base. Initial pool size $200,000. Lock LP tokens for 365 days.
- Month 6: Expand to Arbitrum. Pool size $500,000. Lock LP tokens for 365 days.
- Month 12: Expand to Optimism. Pool size $800,000. Lock LP tokens for 365 days.
- Month 13: Extend Base lock by 365 days. Pool now $1,200,000.
- Month 18: Extend Arbitrum lock by 365 days. Pool now $900,000.
Under a 1% percentage model:
| Event | Pool Value | Fee |
|---|---|---|
| Base launch lock | $200,000 | $2,000 |
| Arbitrum lock | $500,000 | $5,000 |
| Optimism lock | $800,000 | $8,000 |
| Base lock extension | $1,200,000 | $12,000 |
| Arbitrum lock extension | $900,000 | $9,000 |
| Total | $36,000 |
Under a flat 0.03 ETH model (at $2,500/ETH = $75/lock):
| Event | Pool Value | Fee |
|---|---|---|
| Base launch lock | $200,000 | $75 |
| Arbitrum lock | $500,000 | $75 |
| Optimism lock | $800,000 | $75 |
| Base lock extension | $1,200,000 | Free |
| Arbitrum lock extension | $900,000 | Free |
| Total | $225 |
The cost differential over 24 months of normal protocol operations is $35,775. That differential is not a fee comparison. It is the difference between two treasury allocation decisions — one that routes $36,000 to infrastructure extraction and one that routes $225 to infrastructure and retains the remainder for development, security, or runway.
At no point in this example does the project do anything unusual. It grows, it expands to additional chains, it extends its commitment signals. These are the expected behaviors of a protocol executing its roadmap. Under a percentage model, executing the roadmap costs $36,000 in infrastructure fees that scale with every success. Under a flat model, executing the same roadmap costs $225.
Infrastructure Cost as an Investor Signal
There is a secondary effect of infrastructure cost structure that operates at the investor relations level rather than the treasury level.
When a founder explains to an investor that the protocol’s infrastructure costs scale with the pool’s growth — that every successful capital raise increases the cost of locking the liquidity that raise generates — the investor is receiving information about the protocol’s cost structure that reflects poorly on the founder’s infrastructure decisions. It signals that the team accepted a cost model that penalizes their own success without evaluating the alternatives.
When a founder can state that infrastructure costs are fixed, fully budgeted, and will not change regardless of how much capital the protocol attracts, they are communicating operational precision. The budget is defensible. The cost structure does not create contingent claims on the treasury at unpredictable times. The infrastructure decision reflects the same discipline the team is expected to apply to every other operational decision.
Predictable costs are not just a treasury benefit. They are a signal of operational maturity.
Conclusion
Percentage-based infrastructure fees are not a pricing model calibrated to the cost of the service. They are a revenue extraction mechanism calibrated to the project’s capital formation success. The service — creating a lock contract, enforcing a vesting schedule, issuing a verified on-chain commitment — costs the same to execute regardless of whether the locked value is $10,000 or $10,000,000. The cost difference is not a function of the service’s complexity. It is a function of the project’s growth.
Flat-fee infrastructure inverts this relationship. The cost is fixed at a level that reflects the operational reality of the service. It does not change because the pool grew. It does not change because a new chain was added. It does not compound across lock extensions. It is calculable at budget time and permanent thereafter.
For founders building budget models, the implication is direct: infrastructure should be a fixed line, not a variable. Choosing a provider whose fee scales with pool value is choosing to introduce a success-correlated cost into the budget — a cost that will always be highest at the moments when the project’s capital is most usefully deployed elsewhere.
The infrastructure cost should be the last thing that grows when a protocol succeeds. Under a flat model, it does not grow at all.
0xKeep operates on an immutable, zero-admin-key architecture. No wallet — including those controlled by the 0xKeep team — can pause, modify, or interact with deployed contracts. Time is the only admin.
Deploy on Base, Arbitrum, or Optimism at 0x-keep.xyz Follow protocol updates: @0xKeep_official