There is a UX problem coming for every chain that hosts heterogeneous workloads, and the standard answer breaks under load.
The problem. Imagine a chain hosting two schemas at once. One is AI-provenance receipts at millions of attestations per day, mostly automated, low-fee, latency-sensitive. The other is sovereign-identity proofs at hundreds per day, high-value, willing to pay 100x more per attestation. Now imagine a busy day on the AI schema. Under EIP-1559, the chain-wide base fee spikes. The identity schema, which had nothing to do with the spike, now pays a surcharge on every attestation it submits. Two workloads sharing gas they should not share.
Ethereum has lived with this for years. It works there because the chain hosts everything (so workload heterogeneity is just "the way it is") and most applications are price-insensitive enough to absorb the noise. Attestation-native chains break the assumption. The schema is the natural fee-market unit, not the chain.
The full paper is at v0.1: github.com/ligate-io/ligate-research/blob/main/papers/per-schema-fees/per-schema-fees.md. This is the why and the rough how. v0.2 lands once devnet has real schema traffic to calibrate against.
The mechanism, in plain English
Each registered schema gets its own EIP-1559-shaped fee market. Per-schema base fee. Per-schema target utilization. Per-schema tip auction. The base fee adjusts based on the schema's own demand, not the chain's average demand. An AI schema spike does not move the identity schema's price. That's the central idea.
Defaults we are recommending:
- Target utilization 0.5 as the chain-wide default, matching EIP-1559's calibration. Bursty workloads (Kleidon mint events, Iris real-time agent actions) drop to 0.3 for more headroom. Stable low-volume workloads (regulatory filings) push up to 0.7 because variance is low and we can pack closer to demand peak.
- Max change ±12.5% per block. Aggressive enough to track demand shifts, gentle enough to avoid oscillation. Same as EIP-1559.
- Burn split with a schema rebate. A chain-wide burn (governed by PoUA's adaptive τ_burn rebase) plus an optional per-schema rebate, capped at 50%, routed to the schema registrant. So the team that builds a popular schema earns ongoing fee revenue from its traffic. This is the "build on Ligate" path: register a schema, fund the attestor set, earn the rebate.
Why this composes with sponsored gas
Iris is Ligate's MCP server plus USD-billed relayer for autonomous AI agents. The agent runs MCP, the relayer pays gas in $LGT, the user pays Iris in USD. For this to work cleanly, the chain has to understand that the fee payer and the attestor can be different addresses on the same transaction.
Per-schema fees compose orthogonally with that. The relayer pays the per-schema base fee plus tip on behalf of the agent. The schema's fee-routing rebate flows wherever it normally would (typically the schema registrant, not the relayer). The agent's fee experience is "Iris pays". The relayer's variance-management problem is "subscribe to the schema's fee curve and price the USD bill on top". The chain stays out of the USD conversation entirely; the relayer absorbs that on its own books.
This is one of those compositions that sounds obvious once you write it down and is wildly painful to retrofit later. The reason we want it as a runtime primitive is that the fee-payer-vs-attestor split has to be cheap, mempool-level, and uniform across schemas. A contract-layer paymaster introduces gas overhead and per-deployment variance that neither the relayer nor the schema can cleanly price.
What we haven't fully solved
Three open questions v0.2 has to answer.
Cross-schema arbitrage. A validator who preferentially proposes high-fee-schema attestations earns more. Unchecked, that becomes a censorship vector against low-fee schemas. We rely on PoUA's §A.1 KL-divergence detector to catch it: validator schema-mix that drifts from the chain-wide null distribution gets flagged. The detector calibration assumes a chain-wide reference distribution, not a per-validator one. We think this works. Empirical validation has to wait for real devnet traffic.
Fee-griefing. An adversary submits high-tip attestations to a target schema to drag its base fee up, making legitimate users pay more. Bounded by the per-block max-change parameter, but the bound is per-block, not per-attack. Persistent griefing is more expensive than a one-shot but not zero-cost. We have a sketch of how to detect sustained anomalous tip behavior. We do not have a clean proof of the bound.
Sponsored-gas adversarial patterns. An Iris-paid agent submits a flood of attestations to exhaust Iris's budget. The per-schema fee curve does not defend against this on its own; the relayer has to rate-limit at the application layer. Two-layer defense is correct in principle. We have not formally verified the composition is tight under adversarial budgets.
Where to argue with us
Paper at v0.1 has the mechanism. §4.1 carries the per-block adjustment formula, §4.4 the burn split, §4.5 the PoUA integration. v0.2 adds the formal proposition, the cross-schema-arbitrage cost-to-attack analysis, the calibration recommendations against real traffic, and the limitations.
If your area is mechanism design, fee-market calibration, paymaster economics, or attestation-workload pricing, the issue tracker is here. Open one, push back on the τ_burn composition, tell us what we are missing on cross-schema censorship. We argue back when we have time.
This is paper two of six in the research repo right now. PoUA is in external review. Native delegation has its own post. Per-schema fees is here. Native DA, cross-schema composition, time-locked attestations are still working drafts at v0.1. The repo is the place that gets rewritten as we find out which parts are wrong.