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 makes one 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
• user value: any value intentionally sent to the contract

Unused fee budget is refunded automatically when the transaction finalizes. Price caps are locked at submission time; if network prices rise above a cap before execution, the transaction is rejected and nothing is charged.

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