docs(protocol): clarify expiry limits and precompile gas costs

src/pages/docs/protocol/fees/spec-fee.mdx

@@ -174,17 +174,21 @@ If validators have not specified a fee token preference, the protocol falls back
 
 ## Gas Parameters
 
-As of T7, Tempo uses the following mainnet gas parameters:
+Tempo uses the following mainnet gas parameters:
 
 | Parameter | Value |
 |-----------|-------|
 | Base fee cap | 12 billion attodollars per gas (`1.2 × 10^10`) |
 | Base fee floor | 600 million attodollars per gas (`6 × 10^8`) |
 | Total block gas limit | 500M gas |
 | General gas limit | 30M gas/block |
+| Precompile input | `30 × ceil(calldata_length / 32)` gas ([TIP-1100](https://tips.sh/1100)) |
+| Duplicate validation | 20 gas per value processed ([TIP-1105](https://tips.sh/1105)) |
 
 A standard TIP-20 transfer (~50,000 gas) costs approximately 600 microdollars ($0.0006) at the cap and approximately 30 microdollars ($0.00003) at the floor.
 
+Precompile input charges include the selector and are deducted before dispatch and ABI decoding. Duplicate-check charges apply to AccountKeychain call scopes and ZoneFactory role lists before sorting. Calls require canonical ABI encoding without gaps, overlaps, trailing bytes, or nonzero padding.
+
 ### Removing validator preference
 
 To remove a validator token preference, set it to the zero address:

src/pages/docs/protocol/transactions/AccountKeychain.mdx

@@ -13,6 +13,8 @@ The Account Keychain precompile manages authorized Access Keys for accounts, ena
 
 `authorizeKey(...)` takes a `KeyRestrictions` tuple that bundles expiry, spending limits, and call scopes. `authorizeAdminKey(...)` provisions an admin key for account key management. Access-key-signed transactions cannot create contracts; use a Root Key for deployment flows.
 
+See [gas parameters](/docs/protocol/fees/spec-fee#gas-parameters) for calldata requirements and gas charges.
+
 ## Motivation
 
 The Tempo Transaction type unlocks a number of new signature schemes, including WebAuthn (Passkeys). However, for an Account using a Passkey as its Root Key, the sender will subsequently be prompted with passkey prompts for every signature request. This can be a poor user experience for highly interactive or multi-step flows. Additionally, users would also see "Sign In" copy in prompts for signing transactions which is confusing. This proposal introduces the concept of the Root Key being able to provision a scoped Access Key that can be used for subsequent transactions, without the need for repetitive end-user prompting. T6 extends this model with admin access keys for key management. Recurring spending budgets and explicit call scoping make limited keys suitable for subscriptions, connected apps, and session-key-style flows.

src/snippets/tempo-tx-properties.mdx

@@ -1557,7 +1557,7 @@ The [expiring nonces specification](https://github.com/tempoxyz/tempo/blob/main/
 - Automatic replay protection via circular buffer
 - No permanent state bloat from unused nonce keys
 
-Expiring nonces can be used by setting `nonceKey` to `maxUint256` and `validBefore` to a time in the future (within 30 seconds).
+Set `nonceKey` to `maxUint256`, `nonce` to `0`, and `validBefore` to a Unix timestamp in seconds satisfying `now < validBefore <= now + 300`, where `now` is the current block timestamp. The maximum window is five minutes; SDK defaults may use shorter windows. See [TIP-1093](https://tips.sh/1093).
 
 <Tabs stateKey="library-exp">
   <Tab title="Viem">
@@ -1781,7 +1781,7 @@ Expiring nonces can be used by setting `nonceKey` to `maxUint256` and `validBefo
       access_list,
       nonce_key, // set to `maxUint256` // [!code focus]
       nonce,
-      valid_before, // set to `now + <30 seconds` // [!code focus]
+      valid_before, // e.g. `now + 20`; maximum `now + 300` // [!code focus]
       valid_after,
       fee_token,
       fee_payer_signature,