Fees and Transaction Policy

GenLayer apps should treat fees as a measured application policy, not as ad hoc math at submission time. Whether you are building a web frontend, a backend service, a CLI or an automation script, the transaction must include fee parameters that are large enough for the path it can execute.

The suggested fee parameters come from a developer fee profile generated by the contract test suite. @genlayer/transaction-kit is the recommended frontend integration, but the profile itself is not tied to transaction-kit.

The model

Every transaction reserves one protocol-fee deposit up front. The deposit covers:

• consensus work: leader and validator time units, priced in GEN per time unit
• execution budget: receipt, storage and rollup writes
• message budget: child transactions emitted by the contract

For a payable call, user value is transferred separately from that fee deposit; the wallet must cover both. Unused fee budget is refunded automatically when the transaction finalizes. The transaction submits user price ceilings and escrows against those ceilings. Storage and receipt ceilings are checked at submission and top-up; their live prices are then locked at activation. The GEN-per-time-unit price is also locked at activation, but if it has risen above its ceiling, activation cancels the transaction before consensus work and refunds the escrow.

The pieces

Recommended workflow

1. Write normal contract tests for the app paths users can trigger.
2. Add fee-profile coverage for each economically meaningful branch.
3. Run the profile tests against a fee-reporting Studio or network.
4. Commit the generated fee-profile.json where your app or tool can load it.
5. Use the profile entry for the deploy or method you are submitting.
6. Estimate with the current network fee policy and submit the returned distribution and feeValue.

This avoids live simulation before every user transaction. GenLayer transactions can include LLM calls, web requests, appeals and emitted messages, so per-click simulation would make the app slow and expensive. The profile gives the app a reproducible, test-backed estimate; the SDK still reads current prices and caps from the network when the user is about to sign.

Tooling