An investor submits a redemption. The token burn confirms, their holding decreases, and the portal shows a transaction receipt. The next question is practical. Where is the payment?
An RWA redemption crosses two systems with different evidence. The blockchain can confirm a token operation. An offchain settlement process must account for the payment. A portal needs to keep both records visible and avoid marking the entire request complete merely because the burn succeeded.
Aurum RWA’s local implementation makes this separation explicit. It records a redemption request, locks units, reviews the burn and then manages settlement evidence through a separate approval flow. Its current manual settlement provider records and reviews payment information. It does not initiate a bank transfer. The demonstration uses simulated assets and settlement documents.
Freeze the amount before operations begin
A redemption begins with a quote. The useful record includes the quantity, token decimals, price, fee basis, currency, currency scale, expiry and terms version. Saving only the number of tokens leaves the payment amount dependent on whatever pricing happens to be current later.
The Aurum quote model calculates gross, fee and net amounts using integer arithmetic. Its lock authorization binds the request to the wallet, slot epoch, quantity, terms hash, operation identifiers and deadline. These are implementation details with a direct operational purpose. A reviewer can tell which request an authorization belongs to and whether its terms have changed.
For an illustrative request worth 1,000 currency units before fees, with a 10-unit fee, the settlement obligation is 990. Those numbers are synthetic. A portal should show the gross amount, fee and net payment separately, rather than forcing support to reconstruct them from a transaction explorer.
Keep the burn receipt beside the settlement record
The prototype creates a settlement record after processing the confirmed burn. It retains the burn transaction hash and confirmation time on the redemption. The settlement record carries the expected net amount, currency and beneficiary snapshot.
That gives the application two independently useful answers. It can identify the onchain operation that consumed the units, and it can identify the settlement record that operations must complete. The records are linked through the redemption ID.
A simple state view is more useful than a single progress percentage.
| Stage | Evidence to inspect | What remains |
|---|---|---|
| Units locked | Lock operation and reserved quantity | Review and authorize the burn |
| Burn confirmed | Matching burn operation and canonical receipt | Complete the payment process |
| Settlement pending | Expected amount, currency and beneficiary version | Record settlement evidence |
| Settlement review | Payment reference and evidence files | Independent approval or rejection |
| Completed | Confirmed settlement review linked to the redemption | Retain the audit trail |
This table summarizes the flow. It is not an exhaustive list of every intermediate state in the implementation.
Treat an uploaded receipt as something to review
In Aurum, recording settlement evidence requires the expected settlement version, amount, currency, beneficiary version, external reference and evidence document IDs. The service checks the amount and currency against the settlement record. It rejects a future payment timestamp and a reused external reference within the provider and organization scope.
The submission enters review. A separate actor must approve it. The decision checks that the approval still refers to the current settlement and beneficiary version, and it rechecks the canonical burn. Only an approved settlement review moves the redemption to completed.
These controls preserve who asserted what and who reviewed it. They do not make a document uploaded by an operator equivalent to a bank-confirmed payment event. If a future deployment connects a payment provider, the integration needs its own event validation, reconciliation and failure handling. That work should be scoped explicitly.
Recover without repeating the destructive step
Suppose the burn succeeded but the settlement evidence was rejected. A retry should continue from the payment problem. It should not create a second redemption and burn another set of units.
The local implementation has a settlement-failed path and a retry action. Beneficiary changes also use a separate approval request. An approved change increments the beneficiary version and returns settlement to pending, so old evidence cannot silently approve the new destination.
Use this distinction in support tooling. Show the burn status even while settlement needs attention. Give the operator the failed reason, the latest beneficiary version and the pending review. If the canonical burn cannot be established, hold the settlement action for investigation. A missing chain observation is not a reason to guess whether units were destroyed.
Put the uncomfortable cases in the acceptance plan
A useful demonstration includes a duplicate payment reference, an incorrect currency, a stale beneficiary version and an attempt by the submitter to approve their own evidence. It also includes a successful burn followed by a settlement failure. The investor view should still explain what happened and what remains.
Download the redemption handoff and recovery checklist. It provides evidence fields, operator responsibilities and failure scenarios to use during a design review. No live bank connection or real payment is included.
Aurum RWA provides the local workflow described here. If you need a redemption portal, start the discussion with your settlement method, review roles and recovery responsibilities. Those decisions determine how the software should connect token operations to the payment process your team actually uses.
