Launch something people can verify

Before you start

Bring the five previous lesson outputs. If any asset identity, authority path or success condition is still unknown, keep that item visibly unresolved. This exercise makes a launch decision on paper; it does not enable a service.

Your outcome: Assemble a small release packet with evidence, stop conditions and named responsibilities that a second person can review.

Review Wallet Basics · Jump to the guided worksheet · Common problems · What to keep

Words you will use

Release manifest

A record identifying the exact software/configuration version and intended behavior being released.

RPC

The request interface an application uses to read from or submit to a ledger server. An unavailable server does not prove an action failed.

Reconciliation

Comparing stored application records with authoritative outcomes and resolving differences.

Rollback

Returning software to an earlier safe state; it does not undo a validated ledger transaction.

LastLedgerSequence

A transaction upper ledger bound used to limit how long it may be included. Final non-inclusion still requires adequate ledger evidence.

Publish a project contract

Write down the problem, intended user and smallest useful outcome. Publish exact asset identities, account roles, remaining issuer authority, product fees and network costs. Distinguish a prototype, a test-network rehearsal and a working Mainnet feature. Avoid promising profit, permanent availability or a security guarantee you cannot establish.

Rehearse the unhappy paths

Use separate test accounts and a non-production network. Rehearse rejected signatures, expiry, insufficient funds/reserve, wrong network, unavailable RPC and duplicate callbacks. Keep secrets outside frontend assets and logs. Verify current wallet support and amendment availability for the actual network; a documentation page is not evidence of activation everywhere.

Make submission recoverable

Record the transaction hash and intended operation before treating a retry as a new request. Submission responses can be provisional. Track validated ledger results and bounded expiry using appropriate transaction fields such as LastLedgerSequence. A missing lookup can reflect incomplete history or a lagging server; it is not automatically proof that a transaction never executed.

Operate after the first success

Keep a release manifest, rollback plan and protected backup. Separate a reversible UI rollback from an irreversible ledger action. Decide who monitors failures, reconciles payments and answers support. A status page should distinguish healthy service, stale data and disabled features. Test restore procedures before relying on them.

Hold a tabletop launch review

The club wants to open bookings. One person plays the member, one operates the app and one checks the evidence. A single learner can take the roles in turn. Use fictional records only, and write what evidence each role would need.

1. Assemble the asset specification, NFT inspection sheet, trust-line worksheet, authority map and signing-state diagram. Mark each feature as paper design, local simulation, network rehearsal or operational feature. Evidence for one stage is not evidence for every later stage.
2. Choose the smallest useful release. For example, publish a read-only workshop catalog first while payments remain disabled. Name the person allowed to enable payments later and the evidence they must review. A polished button should not hide an unfinished dependency.
3. Create a failure table with input, expected user message, stored state and recovery. Include rejection, wrong signer/network/asset/recipient, insufficient delivery, request expiry, network outage, duplicate callback, restart and stale data. For each, state what must never happen: no false receipt, duplicate entitlement or silent second payment.
4. Rehearse an uncertain transaction: a hash exists but a lookup cannot find it. Keep the original intent and bounded expiry evidence. Ask whether the queried server has the required history and has passed the relevant ledger boundary before concluding non-inclusion. Do not issue a fresh payment merely because one lookup was empty.
5. Separate recovery layers. Reverting a page can hide a bad button; restoring a database can lose newer legitimate receipts; neither reverses ledger transfers. Document backup boundaries, restore verification and how reconciliation preserves transactions after the backup point.
6. Assign named owners for release, support, ledger reconciliation and incident response. Define a stop condition, such as unreliable payment verification, and a containment action that disables new requests while retaining receipts and pending-order status. Test that users can still find help.
7. Write a release decision with exact version, network, enabled features, known limits, test evidence and unresolved items. Let the checker choose ready for the stated stage, hold for evidence or reduce scope. A test pass is evidence, not permission to change somebody else production system.

Optional: connect the worksheet to a public record

Take one official reference used by your project and note its date, required amendment, target network and any warnings. Compare those requirements with your proposed release packet. A documentation page existing is not confirmation of network activation. Record evidence for the exact environment, then ask what changes if a wallet or server does not support the feature.

Official XRPL explorer directory · Network amendment references. Merely reading a public record does not need a wallet. Do not enter private or personal information in these exercises.

Common problems and what to check

A dashboard says healthy while data is old

Display the last successful data time and distinguish service availability from fresh information. Alert on the failure that matters to the user.

A retry could make two payments

Recover the original request and ledger result first. A new intent needs an explicit decision after safe resolution, not an automatic response to timeout.

A rollback would reopen an old security flaw

Use a safe disabled state or forward repair instead. An earlier version is not automatically a safe rollback target.

What to keep before moving on

Deliver the six-part release packet plus a failure table and stop/recovery plan. Explain one unresolved item without disguising it. This completes the foundation course, not professional certification or a production security audit. For implementation, use the linked official tutorials in a separate test environment and arrange review appropriate to the feature.

Explain your answer without looking at the worked example, then compare. If you guessed, revisit the relevant section. The checkboxes and quiz feedback stay on this page only; keep your project notes yourself.

Check your understanding

Go deeper with official sources

• Reliable transaction submission
• Xaman implementation checks
• Current XRPL documentation

Technical references checked 3 October 2026. Network amendments, wallet support and reserve rules can change. Check current documentation before implementing real transactions.

Keep building