10. Resources and pricing
Every command consumes bounded resources and is paid for in credits. This chapter defines the three resource dimensions a block and a command may not exceed, how a command's worst-case consumption is reserved before any work is done, what the price table charges and what it leaves uncharged, and the unit in which every price is expressed. The fee and deposit transitions those prices drive are defined in section 9.
10.1 Resource dimensions
A command's resource vector has three independent hard dimensions, which apply per command and per block.
| Dimension | Measures |
|---|---|
block_bytes |
canonical bytes |
work_units |
reserved work, weighted by the work-weight table of section 10.2 |
new_records |
gross record creations, counting implicit records and never netted against deletions |
R-10.1. A block or command that exceeds any one of the three dimensions is invalid.
R-10.2. The dimensions never convert into one another.
R-10.3. Every command reserves its worst-case vector from its payload shape before signature verification, and a state-dependent reduction never returns reserved capacity.
INV-CONS-04. A block never exceeds any of the three resource dimensions, and they never convert.
10.2 Work weights
Work weights are a compositional table whose components are base, signature family, per-element,
per-proof-node, per-crypto-op, and per-permanent-add. The table is committed by
work_weight_table_id.
R-10.4. work_weight_table_id is bound to price_schedule_id, so an old signed command can
never be repriced under a new table.
R-10.5. A command is valid only if its price_schedule_id equals the price schedule active at
the height it executes, so a command bound to any other price schedule, including the predecessor of
a changed schedule, is invalid at execution and not merely dropped at admission (section 7).
The intent's ruleset_id plays the same role for semantics that price_schedule_id plays for
prices. Dropping commands at admission whose ruleset_id or price_schedule_id will not be active
at the earliest height they can be included is a node policy that never changes validity; it is
specified in ../docs/operations.md.
10.3 The price table
Charging uses a fixed chainspec price table, whose launch values are in section 19. There is no dynamic base fee. Its entries are the canonical byte, the reserved work unit, the record creation fee per family, the record deposit per family, and the username year.
R-10.6. A record creation charges its family's creation fee and locks its family's deposit, and a replacement pays a fresh fee and locks a fresh deposit (section 9).
R-10.7. An update pays bytes and reserved work, plus the lease price when extending or restoring a username.
R-10.8. A discharge returns the stored deposit to its stored payer and never returns a block's reservation (section 9).
R-10.9. The payer is always the signing account, and paying for another account's username extension is allowed and never changes the beneficiary or the deposit payer (sections 7.1 and 8).
R-10.10. System commands and both KEY_REVOKE variants carry no command fee and remain fully
metered against all three dimensions (section 7.3).
R-10.11. The first-import ledger creation fee is the explicit exception for IMPORT_CREDITS, and
is charged to the proved beneficiary under section 9.
R-10.12. No availability layer can debit an account's credits; object storage is billed under a
separate service-level plan (see ../docs/availability-profile.md).
10.4 What a reservation covers
R-10.13. The worst-case resource vector includes every indirect read and write enumerated for execution in section 12, including refund-payer ledgers and slug claims.
R-10.14. A same-key replacement reserves a creation even though it does not increase the resident key count, and a delete or a deposit discharge never offsets a gross creation reservation.
R-10.15. Activation-installer work, including marker creation, is reserved before commands and is included in the same block limits (section 18).
R-10.16. A release qualifies only if its installer is proven to fit under its activation parameters (section 18).
R-10.17. An uncharged governance operation is never exempt from the work or creation bounds.
10.5 Permanent-record economics
R-10.18. The creation fee of a permanent family is calibrated to include a retention component, which is a calibration item of section 19.
History is retained in the store and in the mirror, funded by that retention component, and a range
is lost only if the exporter's publication queue, the store, and the mirror all lose it
(section 17). Who funds that retention, and the absence of an on-chain fund for it at launch, is
specified in ../docs/operations.md.
10.6 The credit unit
A credit is the unit in which every price is denominated and every ledger balance is held. One credit is one microdollar, that is 10^-6 USD, the same scale as TIP-20's fixed six decimals, so a deposit of a USD-pegged TIP-20 token converts to credits one to one with no rescaling.
R-10.19. Every price in the chainspec price table is a whole number of credits.
R-10.20. The settlement contract accepts exactly one asset, fixed in the contract's code (section 16), whose declared currency is USD and which has six decimals (see the settlement interface).
R-10.21. Admission never changes validity (section 12).
Any other asset, and any asset in another currency, is out of scope until an oracle path exists. Credits are real value
imported from Tempo, so block capacity times price is the cost to saturate the chain (section 16).
Proposer selection SHOULD be per-account fair share; that policy is specified in
../docs/operations.md.
10.7 Rationale
This subsection is informative.
Credits are denominated in microdollars because the accepted settlement asset carries six decimals and is the settlement chain's USD unit; aligning the credit to that scale removes a conversion and keeps price tables legible. Permanent records carry an explicit one-time price because they are the one class of state no transition ever removes, and the retention component of that price is what pays for keeping them readable. There is no fee market: worst-case resources are reserved from the payload shape, and contention is governed by admission rate limits rather than by an auction. Three non-convertible dimensions are used instead of one gas-like unit so that a cheap dimension can never be spent to exhaust an expensive one.
How records are ordered, executed, and finalized.