Fees and transaction lifecycle

RP1 separates transaction admission from committed observation. A successful client integration keeps those states distinct and records enough evidence to reconcile a result later.

Lifecycle

signed envelope
    ↓
admission / broadcast acknowledgement
    ↓
DAG certification and ordering
    ↓
application execution
    ↓
committed observation through RPC or REST

The exact latency depends on network conditions, validator configuration, workload, and query cadence. Do not turn a benchmark result into a universal service-level promise.

Fee policy

• Fees are paid in the network’s accepted denom and are configured per environment.
• The smallest positive native unit is 1 urp1; a valid zero-fee local or network transaction is not proof that all endpoints accept zero fees.
• The chain includes fee-burn accounting, but an application should not infer economic policy from the existence of the module alone.
• Check the endpoint’s configured minimum gas price and preserve the signed gas limit when reconciling a committed result.

Observation rules

When a transaction matters financially:

1. Keep the exact signed envelope and its SHA-256 identity.
2. Query until the returned hash and envelope match the submitted record.
3. Require a positive committed height and inspect the execution code.
4. Treat an accepted-but-unobserved transaction as unresolved, not as failed or refunded.
5. If the decoded REST message does not match the prepared message, use the retained RPC transaction bytes as the recovery observation and surface a mismatch if they still differ.

See the TypeScript first transaction and Router recovery for concrete examples.