xrpl-dev-portal/docs/_snippets/tutorial-submit-step.md

Take the signed transaction blob from the previous step and submit it to a `rippled` server. You can do this safely even if you do not run the `rippled` server. The response contains a provisional result, which should be `tesSUCCESS`, but this result is [usually not final](../concepts/transactions/finality-of-results/index.md). A provisional response of `terQUEUED` is also OK, since [queued transactions](../concepts/transactions/transaction-cost.md#queued-transactions) are generally included in the next open ledger version (usually about 10 seconds after submission).

{% admonition type="success" name="Tip" %}If the preliminary result is `tefMAX_LEDGER`, the transaction has failed permanently because its `LastLedgerSequence` parameter is lower than the current ledger. This happens when you take longer than the expected number of ledger versions between preparing and submitting the transaction. If this occurs, start over from step 1 with a higher `LastLedgerSequence` value.{% /admonition %}